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ABSTRACT 


U.S.  Naval  Security  Group  (NSG)  community  data  resides  in  disassociated 
systems  with  no  clear  data  hierarchy.  The  NSG's  lack  of  a  central  information  framework 
wastes  money,  consumes  manpower,  and  underutilizes  claimancy  resources. 

To  improve  NSG  data  operations,  an  Enterprise  Information  System  (EIS)  was 
designed  and  implemented  using  Commercial-Off-The-Shelf  hardware  and  software.  First, 
an  Internet  browser-based,  client-server  architecture  was  selected  that  optimizes 
performance,  interoperability,  and  cost.  Next,  a  database  schema  was  designed  and 
instantiated  using  relational  technology.  Then,  web  server  database  access  files  were 
created  that  emphasize  connectivity  and  utility.  Finally,  EIS  integrity  and  privacy  concerns 
were  examined. 

The  protot5T5e  NSG  EIS  optimizes  personnel  and  resources,  improves  data 
accuracy  and  timeliness,  and  enhances  the  Naval  Security  Group's  aggressive  pursuit  of 
information  dominance.  The  proposed  EIS  provides  the  NSG  with  an  affordable  and 
efficient  method  for  bringing  timely  and  accurate  information  to  bear  in  an  increasingly 
information  dependent  military. 
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INTRODUCTION 


A.  BACKGROUND 

The  United  States  Naval  Security  Group  (NSG)  is  a  large  organization  within  the 
Department  of  the  Navy  (DoN)  managing  global  assets  and  responsibilities.  The  NSG 
possess  no  clearly  stated  architecture  for  retention,  forwarding,  and  processing  of  most 
administrative  and  operational  data.  Database  administration  and  archival  criteria  remain 
undefined  for  individual  commands  and  for  the  claimancy  as  a  whole.  This  lack  of 
information  infrastructure  and  hierarchy  wastes  money  and  manpower.  Furthermore, 
considerable  confusion  and  fixistration  is  experienced  among  members  of  the  NSG 
community  who  lack  the  resources  and  guidance  to  meet  ad  hoc  information  requests. 

In  addition,  the  paucity  of  organized  databases  hinders  the  community's  ability  to 
perform  time-based  trend  analysis.  This  inability  prevents  optimization  of  dwindling 
monetary  and  personnel  resources.  Having  timely  and  accurate  information  is  a 
cornerstone  for  both  modem  military  operations  and  21®*  century  management  practices 
and  has  long  since  become  a  necessity  for  the  NSG. 

We  define  an  enterprise  information  system  as  an  intranet  of  shared  data  united  by 
a  single  data  hierarchy.  Subscribers  update  and  query  data  within  a  tailored  system  using 
specific  computer  interfaces.  Such  a  system  provides  all  entities  within  a  community 
efficient  access  to  current  data  for  decision  making.  This  helps  to  eliminate  guesswork 
and  encourages  optimization  of  assets.  There  currently  exists  a  permanent  need  for  a 
reliable  enterprise  information  system  for  the  NSG. 
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B.  OBJECTIVES  OF  THE  RESEARCH 

This  thesis  describes  in  detail  a  model  enterprise  information  system  for  use 
within  the  NSG  and  outlines  the  system  requirements  and  its  basic  operational  features. 
The  thesis  emphasizes  hardware  and  software  requirements,  construction,  and 
maintenance.  A  working  operational  prototype  has  been  created  and  is  available  for 
public  access.  The  objective  of  this  research  is  to  provide  a  working  prototype  that  can 
be  used  as  a  reference  for  constructing  the  actual  system. 

C.  RESEARCH  QUESTIONS 

The  primary  research  question  is:  What  is  the  best  way  to  implement  an 
administrative  enterprise  information  system  for  the  NSG?  The  subsidiary  questions  are: 
1-  Which  hardware  and  software  supports  the  system  best  in  terms  of 

functional  requirements,  support,  and  cost? 

2.  Which  data  model  and  database  schema  should  be  used?  Which  best 
suits  the  existing  chain-of-command  within  the  NSG? 

3.  What  are  the  benefits  of  such  a  system  to  the  NSG? 

4.  How  can  the  security  and  integrity  of  the  data  be  assured? 

5.  What  are  some  of  the  considerations  in  maintaining  such  a  system? 

D.  SCOPE 

The  thrust  of  this  thesis  is  to  demonstrate  that  the  implementation  of  an  enterprise 
information  system  within  the  NSG  is  feasible,  cost-effective,  and  will  improve  the 
operation  of  the  entire  organization.  The  first  step  is  to  compare  the  current  information 
flow  within  the  NSG  community  to  that  of  the  proposed  system.  The  second  step  is  to 
outline  hardware,  software,  and  implementation  decisions  and  analyze  these  choices  in 
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terms  of  functionality  and  cost-effectiveness.  The  third  step  is  to  prove  the  design  of  the 
data  architecture  and  show  how  this  implementation  best  fits  the  needs  of  the  NSG.  The 
fourth  step  is  to  show  how  to  reasonably  assure  the  security  and  integrity  of  the  data 
within  the  system.  Finally,  a  summary  of  lessons  learned  and  recommended  fiiture  work 
is  provided. 

E.  LIMITATIONS 

The  potential  numbers  of  hardware  and  software  implementation  options 
available  are  too  numerous  for  the  scope  of  this  thesis.  For  this  reason,  system 
requirements  are  based  on  compatibility  with  Microsoft  Windows  NT  according  to 
Department  of  the  Navy  [Ref  1]  and  Fleet  Commanders  [Ref  2].  Budgetary  constraints 
within  both  the  Naval  Postgraduate  School  Computer  Science  Department  and  the  NSG 
remain  a  limiting  factor  in  the  design  of  the  system. 

No  consideration  was  made  for  inclusion  of  all  functional  groups  within  the  NSG. 
A  representative  sample  of  the  most  prominent  administrative  and  operational  functions 
was  chosen  for  conceptual  use  within  this  database  system.  This  scoping  was  imposed 
due  solely  to  the  time  requirements  of  coding  an  all-inclusive  application.  This  limitation 
of  functional  areas  does  not  reflect  a  deficiency  in  the  capabilities  of  the  hardware  or 
software. 

In  addition,  the  data  used  to  populate  the  database  itself  is  not  historical.  Every 
effort  was  made  to  use  data  that  closely  simulates  daily  operations  within  the  NSG. 
Further,  the  processing  of  classified  data  was  not  considered,  as  the  Internet  is  the 
primary  means  of  data  communication  on  this  system.  The  migration  of  this  system  to  a 


3 


secure  intranet  would  allow  for  the  processing  of  secure  information  within  this  same 
data  framework.  More  is  discussed  about  this  matter  in  Chapter  Vni. 

F.  ORGANIZATION  OF  THESIS 

Chapter  I  outlines  the  objectives,  scope,  limitations,  and  research  questions  of  the 
thesis.  Chapter  n  introduces  the  reader  to  the  NSG  and  examines  the  community's 
current  methods  of  information  storage  and  retrieval.  The  intent  is  to  construct  a  baseline 
for  comparison  to  the  proposed  system.  Chapter  III  acquaints  the  reader  with  the  basics 
of  data  engineering,  relational  databases,  and  client-server  computing.  In  addition,  this 
chapter  provides  a  justification  for  the  selection  of  the  information  framework  used  in  the 
proposed  system.  It  details  the  benefits  of  implementing  the  proposed  system  from  the 
viewpoints  of  NSG  headquarters,  its  unit  commanders,  and  the  individual.  Chapter  IV 
examines  hardware,  software,  and  implementation  decisions  and  describes  the  physical 
layout  and  basic  utilization  of  each  of  the  selected  components.  Additionally,  this 
chapter  details  how  a  user's  data  requests  and  updates  are  translated  and  processed  by  the 
system  and  how  these  system  components  cooperate  to  ensure  accurate  information 
retrieval.  Chapter  V  provides  a  detailed  examination  of  the  database  schema  and  shows 
the  interrelations  among  the  tables,  fields,  and  data.  Chapter  VI  examines  the  capabilities 
of  the  sample  site  to  include  navigation  through  the  site,  data  input,  and  data  queries. 
Chapter  VH  examines  methods  for  keeping  the  data  uncorrupted  and  disclosing  only 
appropriate  data  to  appropriate  individuals.  Chapter  Vni  includes  a  summary  of  lessons 
learned  and  recommends  further  research  topics  on  for  this  system. 
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n.  THE  NAVAL  SECURITY  GROUP 

A.  INTRODUCTION 

To  fully  realize  the  benefits  of  implementing  an  enterprise  information  system, 
one  must  understand  the  enterprise  itself  The  NSG  is  assigned  Department  of  the  Navy¬ 
wide  responsibilities  for  cryptology  and  Information  Warfare/Command  emd  Control 
Warfare  by  the  Chief  of  Naval  Operations  [Refs.  3,  4,  and  5],  The  NSG  is  composed  of 
over  11,000  officer  and  enlisted  personnel  stationed  within  the  United  States  and  its 
territories  as  well  as  numerous  foreign  countries. 

The  organization's  headquarters  directorate  manages  personnel  in  six  specialized 
technical  groups  permanently  and  temporarily  assigned  to  land-based  sites,  ships, 
submarines,  and  aircraft.  NSG  commands  and  units  are  divided  into  separate 
departments  and  divisions,  many  of  which  possess  a  large  body  of  personnel  and 
equipment  available  for  extended  and  short-notice  temporary  assigned  duty.  Most  often 
personnel  are  deployed  to  commands  not  assigned  to  the  NSG  command  infrastructure. 
Maintenance  of  such  constantly  moving  assets  presents  a  formidable  task. 

Like  most  large  DoD  organizations,  the  NSG  possesses  a  formal  chain-of- 
command.  Individual  commands  report  directly  to  intermediate  authorities.  These 
commands,  in  turn,  report  to  the  headquarters  unit.  Units  composed  of  NSG  personnel 
temporarily  assigned  to  non-NSG  units  use  a  temporary  chain-of-command  for  data 
forwarding  and  submit  duplicates  of  necessary  data  to  certain  NSG  command  elements. 
Since  not  all  commands  perform  exactly  the  same  function,  each  command's  make-up 
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and  structure  is  unique.  The  primary  functional  departments  within  a  typical  NSG 
command  are: 

1 .  Administration 

2.  Budget  and  Supply 

3.  Maintenance 

4.  Operations 

5.  Training 

Any  proposed  enterprise  information  system  must  reflect  only  simple  variations  from  this 
basic  command  organization. 

B.  PRESENT  NSG  DATA  ARCHITECTURE 

The  NSG  currently  possesses  no  common  means  to  store  and  retrieve  data.  Some 
information  (particularly  fiscal  and  personnel  data)  must  be  retained  and  forwarded  to 
higher  echelons  at  periodic  intervals  according  to  DoN  guidelines.  In  other  cases, 
individual  units  are  tasked  with  maintaining  databases  according  only  to  locally  defined 
needs.  With  irregular  guidance  from  overseeing  organizations,  individual  units  rarely 
know  what  data  to  maintain  or  for  how  long.  Each  unit  operates  independently  with 
respect  to  gathering  and  archiving  operational  and  administrative  data.  Most  command- 
level  database  design  and  programming  needs  are  accomplished  by  well-meaning,  self- 
trained  personnel  with  informal  computer  and  database  backgrounds.  In  the  best  case, 
the  experienced  and  conscientious  commander  with  intelligent  and  motivated  personnel 
successfully  anticipates  chain-of-command  requests  for  information.  The  worst  and  most 
common  cases  are  sudden  and  large  requests  for  data  that  has  never  been  organized  or 
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retained  in  any  local  database.  A  data  request  from  a  command  entity  will  fall  into  one  of 
the  three  following  categories: 

1.  The  data  was  not  previously  identified  for  retention  by  the  local 
command  or  the  headquarters  unit.  In  such  cases,  the  data  must  be 
obtained  from  non-automated  files.  Such  scenarios  are  usually 
deadline  driven  and  result  in  manpower  intensive  searches.  Due  to  the 
lack  of  time  and  lack  of  commonality  between  file  systems,  the 
integrity  of  the  data  returned  to  the  requesting  unit  is  often 
questionable. 

2.  The  data  was  previously  identified  for  retention  but  the  method  of 
storage  was  not  specified.  In  such  cases,  the  data  must  be  converted 
by  the  individual  unit  (or  requesting  unit  upon  receipt)  into  the  desired 
format,  forwarded  to  the  requesting  unit,  and  introduced  into  a  new 
database  system.  This  results  in  wasted  effort,  conversion  problems 
with  mismatched  data  types  caused  by  the  use  of  differing  database 
management  systems  (DBMS),  the  added  expense  of  conversion 
software  and  the  manual  reentry  of  the  same  data  into  systems. 

3.  The  data  was  previously  identified  for  retention  and  the  DBMS  was 
the  same  for  both  units.  In  such  cases,  the  data  must  be  delivered  to 
the  requesting  unit  by  courier  or  electronic  mail  and  then  introduced 
into  the  requesting  unit's  system. 

Regardless  of  the  category  into  which  an  individual  data  request  falls,  once  the 
data  has  been  submitted  to  higher  authority,  individual  commands  have  no  means  of 
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accessing  community  information  as  a  whole.  As  such,  many  NSG  individuals  cannot 
view  community  data  that  would  benefit  local  operations. 

Furthermore,  data  is  not  archived  for  consistent  periods  at  individual  commands. 
New  executive  personnel  and  system  administrators  (SA)  bring  new  data  perspectives  to 
an  individual  unit.  As  such,  no  consistent  performance  timelines  are  available  for  any 
units. 
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m.  THE  ENTERPRISE  INFORMATION  SYSTEM 


A.  DATABASES,  THE  RELATIONAL  MODEL,  AND  SQL 

A  database  is  defined  as  a  collection  of  related  data  [Ref  6],  Databases  may  or 
may  not  be  automated  based  on  the  desires,  needs,  and  resources  available  to  the  user. 
For  automated  systems,  there  are  numerous  commercially  available  DBMS  products  from 
various  venders  that  organize  data  on  magnetic  media  using  many  data  schemes. 

The  most  mature  database  technologies  rely  on  a  database  model  known  as  the 
relational  model.  In  this  model,  a  table  of  data  values  is  created  and  specific  data  is 
organized  into  sets  of  data  labeled  by  field  names.  Unique  values,  identified  as  keys,  are 
used  to  distinguish  particular  data  value  combinations  or  tuples.  Each  table  is  then 
related  to  one  or  more  other  tables  based  on  the  relationships  between  these  keys  and  the 
other  data  fields  contained  within  the  table.  When  a  user  queries  (or  updates)  a  database, 
a  unique  tuple  or  set  of  tuples  is  returned  (or  inserted  into)  one  or  more  tables  based  on 
the  user's  request  and  the  relationship  of  the  tables. 

A  database  language  known  as  Standard  Query  Language  (SQL)  was  designed  to 
manipulate  both  the  data  and  data  organization  of  a  database  [Ref  7].  SQL  is  based  on 
mathematical  principles  and  has  undergone  many  revisions  over  the  years.  Many  civilian 
corporations  have  been  operating  SQL-based  relational  database  systems  for  years.  The 
irreplaceable  nature  of  the  accumulated  data  to  these  users  and  the  proven  nature  of  the 
relational  schema  ensure  that  relational  databases  will  continue  to  be  a  foundation  of 
database  systems  even  as  new  database  systems  are  developed  for  the  future. 
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B.  DATABASE  ARCHITECTURE  MODELS 


Database  technology  has  been  enriched  by  the  unparalleled  growth  of  computer 
development  in  the  last  few  decades.  The  faster,  more  capable,  and  less  expensive 
computer  has  enabled  very  large,  very  fast,  sophisticated  multimedia  databases  with 
remote  access.  The  maturation  of  data  technology  has  spurred  the  declining  cost  and 
rising  availability  of  database  systems. 

The  growth  of  computer  communications  and  network  computing  has  enabled 
computers  to  accurately  transmit  and  receive  large  quantities  of  digital  data  very  rapidly. 
To  take  advantage  of  this  technology,  database  engineers  have  devised  architectures  that 
allow  the  networking  of  databases  together. 

The  manner  in  which  databases  are  joined  together  to  achieve  a  coherent  data 
picture  is  known  as  a  database  architecture.  There  are  currently  three  basic  database 
architectures  commonly  in  use  today. 

1.  Stand-Alone 

In  this  model,  a  database  is  instantiated,  operated,  and  maintained  on  a  single 
machine  that  does  not  communicate  with  any  other  to  maintain  this  data.  A  typical 
example  is  one's  personal  computer  where  financial  records  are  kept. 

Most  available  DBMS  software  is  intended  for  operation  in  this  mode.  The 
primary  drawback  to  this  type  of  system  is  that  users  in  differing  locales  do  not  have 
simultaneous  access  to  this  data.  Although  some  of  these  systems  are  being  expanded  for 
use  in  Local  Area  Networks  (LAN),  a  user  must  still  be  physically  present  at  the 
computer  (or  LAN)  that  contains  the  database  in  order  to  manipulate  the  data.  Numerous 
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examples  of  these  types  of  databases  exist  in  NSG  using  such  varied  DBMS  software  as 
Borland's  Paradox,  Microsoft's  Access,  and  Oracle's  Oracle  7. 

2.  Distributed 

In  this  model,  different  types  of  such  locally  maintained  databases  are  linked 
together  over  some  common  network.  An  additional  set  of  hardware  and  software 
provides  translation  and  communication  services  between  the  differing  DBMS  products 
and  database  designs.  In  a  typical  large  distributed  database  system,  a  search  engine 
queries  numerous  databases.  The  appropriate  server(s)  returns  the  desired  response  based 
on  input  from  the  user.  The  main  drawbacks  to  this  type  of  system  are  their  complexity, 
maintenance  overhead  (individual  units  are  responsible  for  keeping  their  systems  and 
data  up  to  date),  cost,  and  performance.  Anyone  who  has  used  a  search  engine  to  recover 
information  from  the  worldwide  web  has  used  a  distributed  database  system. 

3.  Client-Server 

The  client-server  model  utilizes  elements  of  both  the  stand-alone  and  distributed 
models.  In  client-server  computing,  data  processing  responsibilities  are  divided  between 
the  computer  that  wants  a  certain  service  performed  (the  client)  and  the  computer  that 
will  attempt  to  provide  that  service  (the  server).  An  interface  between  the  client  and 
server  makes  the  system  user-friendly. 

The  client  and  server  computers  are  not  required  to  be  co-located  but  may  be 
distantly  connected  by  a  communications  network.  In  client-server  database  systems, 
only  the  database  server(s)  contains  the  DBMS  and  the  database  data.  Any  number  of 
clients  may  query  and  update  the  database.  The  performance  of  the  system  is  limited  by 
the  capabilities  of  the  client,  the  server,  and  the  network  itself  The  main  drawback  of  the 
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client-server  database  architecture  is  that  a  great  deal  of  planning  must  go  into  the  system 
before  it  can  be  properly  implemented.  In  addition,  the  client-server  database  must  be 
flexible  enough  to  account  for  future  data  processing  and  retention  needs. 

Figure  1  shows  a  comparison  of  the  major  advantages  and  disadvantages  of  these 
three  types  of  database  architectures. 


Stand-Alone 

Distributed 
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Data  Accessibility 

Low 

High 

High 

Implementation 
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Medium 
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High 

Medium 

Medium 

Scalability 

Low 

Medium 

High 

Security  &  Data 
Integrity 

High 

Low 

Medium 

Upkeep  &  System 
Administration 

Low 

High 

Low 

Figure  1.  Advantages  and  Disadvantages  of  Various  Database  Architectures 


C.  SELECTING  A  DATA  MODEL  FOR  THE  NSG 
1.  Criteria 

The  competitive  nature  of  the  computer  industry  continues  to  drive  dramatic 
improvement  in  both  computer  hardware  and  software.  These  leaps  in  performance  and 
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capability  are  occurring  over  very  short  periods  of  time  at  minimal  cost  to  the  consumer. 
In  today's  market,  few  can  afford  to  be  constrained  by  the  old  "maintain  and  upgrade" 
strategy.  It  is  far  cheaper  to  purchase  a  newer  and  more  capable  system  than  it  is  to 
upgrade  an  old  one. 

Faced  with  shrinking  force  structures  and  budgets,  the  DoN  now  encourages 
maximal  use  of  such  Commercial-OfF-the-Shelf  (COTS)  equipment  due  to  this  low  cost 
and  relatively  short  development  pipeline  [Ref  8].  The  old  monolithic  military 
acquisition  system  and  stringent  system  of  specifications  for  defense  systems  (MELSPEC) 
have  been  reduced  or  even  eliminated  in  most  cases.  It  is  true  that  there  remain  some 
marked  differences  between  the  requirements  of  civilian  and  military  computer  database 
systems  [Ref  9],  most  notably  with  respect  to  redundancy  and  survivability.  However,  in 
today's  environment,  a  degree  of  flexibility  has  been  granted  to  community  leaders  to 
define  their  data  processing  requirements  and  seek  the  appropriate  computer  solutions. 

For  the  NSG,  a  fully  implemented  community-wide  database  system  must  meet 
many  additional  requirements.  These  requirements  are  stated  in  Figure  2.  Meeting  these 
stipulations  would  ensure  that  the  appropriate  database  system  could  be  realistically 
fielded  in  minimal  time  and  at  reasonable  cost  and  effort  to  the  community. 
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Accessible 

Compatible  with 
databases 


existing  legacy 


All  sites  should  possess  the  capability  to  update 

and  query  selective  portions  of  the  database. _ 

NSG  possesses  large  quantities  of  disconnected 
data  on  older  relational  systems.  The  system 
must  be  capable  of  incorporating  this  data  as 
necessary. 


Compatible  with  existing 
operating  systems 


Easy  for  the  novice  to  operate 


Flexible 


Inexpensive 


PC  Based 


Scalable 


Microsoft  NT  is  the  most  commonly  available 
computer  operating  system.  Use  of  NT  ensures 
compatibility  with  existing  systems  and  easy 
upgrades. _ 

Not  everyone  knows  (or  even  likes)  computers. 
The  system  should  not  require  additional  training 

for  the  common  user  to  operate. _ 

Large  communities  are  dynamic  and  change 
administrative  and  operational  requirements  over 
time.  The  database  should  be  flexible  enough  to 

change  without  losing  historical  data. _ 

The  initial  cost  should  not  be  a  prohibitive  factor 
in  implementing  the  system.  Field  sites  should 
not  have  to  purchase  new  software  to  operate  the 
system. _ 

A  PC  based  system  ensures  that  there  is  no  large 
infrastructure  to  maintain  or  expensive  upkeep 
cycles.  NSG  personnel  continue  to  be  trained  in 

basic  maintenance  of  PC  based  systems. _ 

The  system  should  be  quickly  and  affordably 
upgraded  (or  replaced)  when  it  becomes  too  slow 
or  lacks  sufficient  capability. _ 


Figure  2.  NSG  EIS  System  Requirements 


2.  Selection 


Based  on  the  above  stated  criteria,  the  most  logical  choice  of  database  models  and 
architectures  to  suit  NSG  needs  is  the  relational  database  model  implemented  with  the 
client-server  architecture.  This  selection,  known  as  an  enterprise  information  system 
(EIS),  optimizes  the  existing  NSG  hardware  and  software  inventory  without  requiring 
changes  in  the  basic  chain-of-command  organization. 
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There  are  numerous  relational  database  systems  available  to  the  user  for  operation 
within  a  client-server  environment.  In  order  to  meet  the  compatibility,  cost,  and  ease  of 
operation  benchmarks,  one  stable  software  suite  should  be  chosen. 

The  Microsoft  Corporation  offers  packaged  software  subscriptions  that  include 
comprehensive  software  upgrades  at  no  additional  cost  as  well  as  free  technical  support. 
The  most  practical  of  these  solutions,  the  Microsoft  Developer  Network  (Universal 
Subscription),  is  available  for  an  annual  fee  and  contains  all  of  the  software  necessary  to 
construct  and  implement  an  EIS  that  meets  (and  exceeds  in  some  cases)  the  stated 
criteria.  The  principal  elements  of  this  package  are  the  server  operating  system  (NT 
version  4.0),  the  web  server  (Internet  Information  Server  3.0),  and  the  database  server 
(SQL  Server  6.5). 

D.  BENEFITS  GAINED  BY  EIS  IMPLEMENTATION 

An  EIS  would  greatly  benefit  the  operations  of  the  NSG.  The  principle  benefits 
gained  by  using  the  EIS  architecture  are  described  below.  A  comparison  to  the  existing 
NSG  data  structure  is  also  provided. 

1.  Increased  Functionality 
a.  Capacity 

The  proposed  EIS  database  capacity  is  limited  only  to  the  size  of  the 
server  hard  drive.  SQL  server  does  not  limit  the  number  of  independent  databases  that 
may  exist  on  the  server.  The  data  capacity  of  the  existing  NSG  data  architecture  is 
difficult  to  determine  because  the  same  data  is  not  kept  from  command  to  command. 
Based  on  the  size  of  the  example  database  site  discussed  later  in  Chapter  VI,  an  11,000 
member  NSG  would  conservatively  need  50  gigabytes  of  storage  capacity  per  year. 
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b.  Connectivity 

The  proposed  EIS  allows  every  unit  to  be  connected  to  a  central  database 
through  the  Internet  (or  any  community  wide  intranet).  The  Microsoft  database  server 
allows  in  excess  of  32,000  simultaneous  networked  connections. 

Under  the  present  system,  there  is  no  way  to  access  all  of  the  community's 
data  at  once.  The  existing  structure  limits  the  ability  of  one  command  to  compare  its  data 
to  another.  It  is  very  difficult  to  view  NSG  operations  as  a  whole. 

c.  Data  Accuracy 

Currently,  individual  command  databases,  even  ones  that  are  standardized 
between  separate  units,  cannot  be  updated  at  the  same  time.  NSG  units  are  located  in 
differing  time  zones  and  use  different  update  intervals.  Such  activity  prohibits  accurate 
data  interpretation  by  command  entities.  With  the  EIS,  an  update  occurs  as  soon  as  an 
individual  enters  data  into  the  central  database. 

d.  Data  Interpretation 

There  is  now  no  systematic  way  to  gauge  the  accuracy  of  the  data  passed 
along  the  chain-of-command.  Data  reporting  guidelines  may  be  interpreted  differently  by 
different  individuals.  The  standardized  interfaces  of  the  EIS  will  help  to  resolve  the 
conflicts  of  how  to  interpret  data  from  various  sources.  The  interface  can  be  pre¬ 
programmed  to  accept  data  only  in  certain  ranges  or  at  certain  times.  Data  that  does  not 
meet  the  guidelines  is  rejected.  This  helps  to  ensure  the  database  remains  accurate. 

e.  Historical  Data  Comparison 

An  EIS  allows  automatic  dating  of  information  stored  in  the  database. 
Provided  that  the  database  schema  implementation  does  not  overwrite  data,  all  data  can 
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be  analyzed  with  reference  to  the  time  an  action  occurred.  Most  NSG  historical  data 
comparisons  are  currently  performed  manually. 

f.  Informed  Decision  Making 

High  level  decision  making  scenarios  usually  arise  unexpectedly.  Most 
often  in  today's  workplace,  managers  do  not  have  all  the  information  they  need  to  make 
qualified  decisions.  The  EIS  allows  appropriate  information  to  be  instantaneously  and 
continuously  available  to  all  levels  of  management. 

Additionally,  under  current  NSG  reporting  policies,  periodic  (weekly, 
monthly,  quarterly,  and  annually)  reports  from  subordinate  commands  to  higher  echelon 
authorities  are  the  standard.  When  this  information  is  archived,  only  these  milestones  are 
available  for  view.  Using  the  EIS,  these  guideposts  are  expanded.  All  information  is 
available  all  the  time.  Decisions  may  thus  be  data  driven  instead  of  impromptu. 

g.  Timeliness 

Currently,  many  important  decisions  (budget,  operations,  personnel 
matters,  etc.)  are  often  delayed  because  all  outlying  commands  cannot  gather  and  submit 
required  information  in  a  timely  manner.  These  occurrences  are  rarely  the  fault  of  the 
individual  unit.  Such  situations  arise  because  the  current  system  relies  on  manual  transfer 
of  paper  or  magnetic  media  that  are  subject  to  a  number  of  factors  outside  the  control  of 
the  individual  unit.  Under  the  EIS,  the  timeliness  of  an  update  is  limited  only  by  the 
status  of  the  computer  equipment.  As  long  as  units  make  inputs  as  appropriate  data 
arrives,  the  results  of  a  query  are  always  current. 
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2.  Optimized  Use  of  Personnel 

a.  Database  Consistency 

The  current  system  requires  many  people  at  many  sites  to  maintain  data 
consistency.  Each  site  usually  has  a  different  set  of  relational  tables  located  on  a  different 
computer  with  a  different  DBMS.  When  data  is  forwarded  to  command  authorities,  a 
team  at  each  command  site  is  required  to  manually  combine  the  polled  data  into  yet 
another  database.  This  is  accomplished  by  reformatting  the  data  to  fit  the  new  structure 
or  manually  reentering  the  data.  As  an  example,  Pacific  NSG  commands  currently 
submit  TAD  (temporary  additional  duty)  expenditures  by  magnetic  disk  to  the  NSG 
element  of  CINCPACFLT  (Commander-if-Chief)  for  reentry  into  a  larger  system. 

This  method  is  far  too  labor  intensive  and  does  not  make  maximum  use  of 
available  technology.  The  EIS  uses  networking  to  make  all  updates  automatically  to  the 
same  database  on  the  same  server.  Thus  the  database  is  always  consistent  and  no 
database  experts  are  required  at  the  local  or  intermediate  commands. 

b.  Database  Design  and  Upkeep 

A  change  in  the  NSG  community  currently  requires  a  commensurate 
change  to  multiple  databases  and  database  formats  throughout  the  claimancy.  With  the 
EIS,  when  a  change  in  the  community  requires  a  change  in  the  database,  the  database  has 
to  be  changed  only  once  at  the  server  level.  There  is  no  longer  a  need  to  notify 
commands  to  change  a  certain  field  within  a  certain  table  or  rely  on  the  local  command 
expert  to  understand  the  problem  and  implement  an  appropriate  solution.  One  person  at 
the  headquarters  level  can  make  the  change  once  for  the  entire  community. 


3.  Reduced  Training 

Presently,  people  have  to  be  trained  to  use  a  variety  of  different  DBMS  software. 
Users  must  learn  a  wide  variety  of  technical  skills  to  ensure  proper  maintenance  (how  to 
create  and  change  the  database)  and  use  (how  to  enter  data  and  make  queries)  of  a 
DBMS.  Because  of  numerous  DBMS  applications  within  the  NSG  non-standardized 
training  practices  are  common. 

The  EIS  uses  Internet  browser  technology  to  update  and  retrieve  data.  Most 
computer  users  are  familiar  with  how  to  use  the  World  Wide  Web.  For  those  that  are  not, 
a  browser  is  much  easier  to  learn  than  how  to  operate  any  stand-alone  DBMS. 
Implementing  an  EIS  would  require  training  of  only  the  team  at  the  headquarters  unit  that 
conducts  maintenance  and  change  to  the  server-based  system. 

Another  problem  that  currently  exists  is  that  commands  periodically  lose  their 
database  experts  due  to  normal  military  duty  rotations.  Most  often,  operations  are 
hampered  while  another  expert  is  found  or  trained.  When  all  database  design  and  update 
occurs  at  one  central  location,  community  planners  can  more  easily  maximize  personnel 
resources,  training,  and  plan  for  contingencies. 

4.  Reduced  Cost 

a.  Initial  Purchases 

At  the  moment,  implementing  a  new  database  requires  a  separate  DBMS 
for  each  database  that  is  to  be  created,  as  well  as  a  computer  (perhaps  many)  at  each 
command.  The  cost  of  the  Microsoft  subscription  is  $2499  annually  [Ref  10].  Currently 
the  costs  of  DBMS  site  licenses  alone  far  exceed  this  price  tag.  As  an  example,  consider 
Borland's  Paradox  7  for  Windows,  one  of  the  most  prominent  stand-alone  DBMS 
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products  in  use  in  the  NSG.  Purchasing  one  initial  system  ($349.95)  and  four  one-user 
site  licenses  ($1 19.95)  for  only  twenty  sites  would  total  $16595  [Ref  1 1],  This  does  not 
include  the  cost  of  upgrade  packages  or  shipping  and  handling. 

The  only  unique  cost  to  the  EIS  is  in  the  purchase  of  new  hardware. 
Hardware  specifications  will  be  discussed  in  detail  in  Chapter  IV.  A  suitable  server  with 
a  back  up  would  cost  less  than  $10,000  on  the  commercial  market.  The  computers  used 
at  various  commands  solely  for  database  applications  could  be  freed  to  perform  other 
functions. 

Should  the  community  wish  to  incorporate  legacy  data  from  older 
systems,  the  cost  to  do  so  within  the  existing  framework  would  be  prohibitively 
expensive.  With  the  EIS,  this  data  insertion  would  only  need  to  be  done  once  instead  of 
once  for  each  pertinent  database  at  a  command  site.  The  selected  database  server,  SQL 
Sever  6.5,  is  capable  of  being  easily  uploaded  with  data  from  most  existing  DBMS 
software,  including  non-Microsoft  products. 

b.  Ongoing  Maintenance 

Upgrades  to  the  DMBS  software  at  commands  can  be  very  expensive  and 
often  cost  as  much  as  the  original  investment.  Vendors  often  distribute  upgrades  and 
technical  support  using  costly  maintenance  packages.  Using  Microsoft's  subscription 
option,  software  upgrades  are  mailed  directly  to  the  database  server  site  as  soon  as  they 
are  publicly  available. 

Additional  costs  are  incurred  when  consulting  services  are  reserved. 
Currently  each  of  the  different  DBMS  software  systems  requires  different  vendor 
services.  The  Microsoft  universal  subscription  contains  limited  free  technical  support 
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and  permissions  within  a  developer's  network  that  lends  assistance  with  technical  issues. 
No  vendor  calls  were  necessary  during  the  construction  of  this  model  due  to  the 
abundance  of  available  reference  material  and  on-line  help. 

The  cost  of  the  couriers  and  mail  services  required  to  transport 
information  from  local  databases  to  headquarters  managers  under  the  current  system  is 
also  noteworthy.  Using  the  EIS  model,  updates  and  queries  are  conducted  over  the 
Internet,  which  does  not  even  incur  the  cost  of  a  long-distance  phone  call. 
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IV.  IMPLEMENTATION 


A.  SYSTEM  DESIGN 

1.  Physical  Layout 

An  EIS  database  must  reside  on  a  server  that  is  electronically  accessible  to 
everyone  in  the  community.  Many  of  the  networks  commonly  in  use  in  the  NSG  have 
stringent  security  features  that  make  them  inaccessible  to  most  computers  at  the  Naval 
Postgraduate  School.  Since  the  Internet  is  the  most  universal  and  least  restrictive 
network  available,  it  was  chosen  for  this  research. 

Theoretically,  the  server  and  all  its  components  could  be  based  at  any  NSG  site. 
The  most  practical  location  is  the  NSG  headquarters  element.  There  are  several  reasons 
for  this; 

1.  The  NSG  headquarters  element  is  located  inside  the  continental  United 
States.  Access  to  dependable  communication  facilities  is  a  necessity  for  a 
reliable  system.  Major  headquarters  sites  tend  to  have  an  abundance  of 
telephone  capacity. 

2.  NSG  Headquarters  is  the  site  where  community  policy  is  formulated  and 
promulgated.  Any  policy  change  requiring  a  change  in  the  database 
structure  could  be  more  quickly  and  easily  accomplished  by  maintenance 
personnel  if  the  server  is  closer  to  the  decision  making  process. 

3.  NSG  Headquarters  already  has  a  functional  Internet  web  site.  Proven 
connections  would  make  installation  and  maintenance  far  simpler. 

Thus,  through  the  Internet,  all  NSG  sites  with  a  computer,  a  connection,  and  a 
web  browser  are  now  capable  of  Internet  connection  to  the  NSG  server.  Figure  3  is 
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provided  to  compare  the  basic  physical  communication  layout  of  the  EIS  to  the  NSG 
command  framework.  Solid  lines  represent  the  formal  chain-of-command  structure  while 
dashed  lines  represent  information  flow. 


2.  Operation 

The  operation  of  the  system  is  designed  around  the  chain-of-command  that  is 
currently  in  place  in  the  NSG.  Presently,  individual  NSG  commands  collect  data  for 
submission  in  the  form  of  daily  reports.  This  data  is  retained  in  hard-copy  files  and 
stand-alone  databases  or  simply  discarded. 

The  focus  of  the  EIS  is  not  to  change  a  command's  reporting  responsibility  but  to 
make  the  manner  in  which  these  actions  are  carried  out  more  efficient.  Instead  of 
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gathering  data,  manually  performing  calculations  on  this  data,  and  then  combining  all  of 
this  into  a  report,  the  operator  uses  the  EIS. 

The  user  logs  onto  the  system,  then  locates,  completes,  and  submits  the 
appropriate  data  using  an  input  form.  This  process  updates  the  EIS  data.  The  EIS 
contains  preprogrammed  query  routines  that  are  available  for  a  number  of  common 
reports.  The  operator  may  select  such  a  report  at  any  time.  The  EIS  performs  the 
calculations  for  the  operator.  This  ensures  that  the  calculations  are  done  correctly  and  in 
a  uniform  manner  from  command  to  command.  Additionally,  the  data  is  permanently 
archived  in  the  central  repository.  Hard-copy  reports  can  be  printed  from  the  browser  if 
desired. 

Individual  units  are  still  accountable  for  their  specific  areas  of  responsibility.  EIS 
operation  allows  commands  to  preserve  their  uniqueness  and  autonomous  nature.  Since 
people  need  not  be  trained  extensively  on  how  to  operate  a  web  browser  and  their 
reporting  responsibilities  are  unchanged,  minimal  interruption  is  expected  when  bringing 
the  EIS  on-line. 

3.  Information  Flow 

When  one  uses  a  web  browser  to  connect  to  the  EIS,  one  types  in  the  Universal 
Resource  Locator  (URL)  or  the  Internet  Protocol  (IP)  address  into  the  browser  URL  box. 
Once  the  correct  address  is  submitted,  the  client  machine  has  the  necessary  information 
for  connection  to  the  server.  Figure  4  shows  the  path  the  user  takes  in  order  to  reach  the 
data  in  the  EIS  database.  It  is  important  to  remember  that  connection  to  a  server  does  not 
necessarily  imply  access  to  the  database.  Selective  access  to  the  data  for  security  and 
data  integrity  reasons  is  covered  in  more  detail  in  Chapter  VI. 
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The  machine  address  is  passed  to  an  Internet  provider  (the  DoD  uses  its  own  hubs 
rather  than  use  commercial  providers)  which  searches  for  the  server  URL  address  on  the 
Internet.  Once  the  correct  server  is  located,  a  connection  is  established  so  that  the  two 
machines  may  exchange  information.  The  EIS  web  server  application,  Microsoft's 
Internet  Information  Server  (IIS),  makes  an  initial  web  page  accessible  to  the  client.  The 
user  is  allowed  access  when  a  given  password  returns  a  positive  match  when  compared  to 
a  corresponding  table  in  the  operating  system  files. 

The  first  page  EIS  displays  server  as  a  kind  of  directory  page.  The  user  may 
navigate  through  any  subsequently  linked  pages  to  which  they  are  granted  access.  Web 
pages  are  linked  together  using  a  protocol  known  as  hypertext  transfer  protocol  (HTTP). 
The  address  of  the  next  page  is  submitted  to  IIS  when  the  user  click  an  object  and  IIS 
fetches  it  or  transfers  control  to  another  web  server  if  it  does  not  control  this  page. 
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EIS  web  pages  are  designed  to  allow  the  user  to  insert,  update,  or  query  a 
database.  To  do  so,  the  web  server  must  connect  to  the  database  server.  IIS  uses  a  pre- 
configured  application  programming  interface  known  as  Open  Database  Connectivity 
(ODBC)  that  tells  IIS  the  server  name,  the  database  name  and  the  criteria  with  which  to 
connect  in  order  to  satisfy  the  client's  request.  An  ODBC  path  name  is  required  in  each 
query  or  update  file  on  the  EIS  server.  It  is  specified  and  controlled  through  the  server 
operating  system  and  is  not  directly  supplied  by  the  user. 

The  system  is  now  ready  to  access  the  database  server.  The  database  can  be 
accessed  with  (an  update  or  a  query  that  prompts  data  fi'om  the  user)  or  without  user  input 
(a  standardized  query  routine).  The  following  steps,  graphically  displayed  in  Figure  5, 
must  occur  in  order  for  the  client  to  access  the  database: 

1 .  The  client  clicks  on  the  desired  page.  This  brings  up  a  web  page  known  as 
a  hypertext  mark-up  file  (HTM). 

2.  This  file  may  reference  another  HTM  that  contains  a  format  for  the  user  to 
perform  input.  This  step  is  omitted  when  user  input  is  not  required.  A 
sample  HTM  file  is  located  in  Appendix  C. 

3.  The  HTM  calls  an  Internet  Database  Connector  (IDC)  file,  which  contains 
the  ODBC  path  name,  additional  connection  parameters,  and  SQL  code. 
The  IDC  communicates  to  the  database  server  which  database  to  use  and 
what  data  should  be  retrieved  (or  updated).  The  SQL  code  outlines  the 
specifications  of  the  query.  A  sample  IDC  file  is  contained  in  Appendix 
C. 
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The  database  server  performs  any  calculations  and  returns  the  data  to  nS. 
The  IDC  file  contains  a  reference  to  another  file  called  a  hypertext  markup 
template  file  (HTX).  The  HTX  serves  as  a  place  to  put  the  data  once  the 
query  has  been  completed.  The  HTX  is  configured  to  present  the  data  in 
any  fashion  the  programmer/administrator  deems  suitable.  A  sample  HTX 
file  is  contained  in  Appendix  C. 

IIS  then  presents  the  HTX  with  the  data  to  the  client  for  the  user  to  view. 


Figure  5.  EIS  File  Interaction 

After  this  process  is  completed,  the  user  can  select  any  other  HTM  displayed  in 
the  HTX  (another  link)  or  use  the  browser  tools  (back,  forward,  home,  etc.)  to  navigate 
through  EIS. 

The  server  operating  system  maintains  all  of  the  IDC,  HTM  and  HTX  file 
structures  and  monitors  all  aspects  of  each  transaction  in  order  to  ensure  proper  operation 
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throughout  the  time  a  client  is  active.  The  web  server  manages  the  user's  connection  to 
the  server  and  presents  the  correct  web  pages  as  selected  by  the  user.  The  database  server 
is  responsible  for  reading  SQL  statements  and  performing  appropriate  operation.  The 
next  section  describes  the  necessary  hardware  and  software  required  to  construct  the  EIS 
using  this  hierarchy. 

B.  SERVER  REQUIREMENTS 

1.  Hardware 

Theoretically,  any  computer  with  a  network  card  and  cabling  can  function  as  a 
server.  Due  to  the  amount  of  processing  a  server  must  conduct  and  the  number  of 
connections  it  might  have  to  maintain,  the  high-end  server  is  faster  and  possesses  more 
capacity  than  the  standard  personal  computer.  Generally,  a  more  powerful  processor  and 
more  Random  Access  Memory  (RAM)  lead  to  a  more  efficient  system.  Microsoft 
recommends  [Ref.  12]  that  any  server  that  runs  NT  4.0  as  an  operating  system  possess  at 
a  minimum: 

1 .  A  90  megahertz  (MHz)  Intel  Pentium  processor 

2.  64  megabytes  (MB)  RAM 

A  90  MHz  processor  is  no  longer  commercially  available  and  is  not  sufficient  for 
serving  many.  A  database  server  with  at  least  Pentium  11  technology  (233  MHz) 
capability  is  recommended.  Servers  that  contain  multiple  processors  would  be  optimal 
for  this  system.  Dual  processor  servers  are  now  commercially  available  for 
approximately  $5000. 
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The  EIS  server  needs  a  large  hard  drive  to  hold  all  of  the  server  software 
packages,  the  application  software,  and  a  number  of  file  creation  tools  (discussed  in  detail 
later  in  this  chapter).  It  also  needs  sufficient  space  to  store  the  large  number  of  HTM, 
HTX,  and  IDC  files  that  the  client  may  access.  A  hard  drive  with  at  least  100  gigabytes 
(GB)  of  active  storage  is  recommended. 

To  construct  the  sample  EIS  site,  the  prototype  EIS  server  was  constructed  using  a 
DELL  Dimension  XPS  Pro  200  personal  computer.  The  system  is  based  on  a  200  MHz 
Intel  Pentium  microprocessor  and  contains  64  MB  of  RAM.  The  server  has  5.96  GB  of 
hard  drive  space  divided  between  two  drives.  It  is  fitted  with  a  3Com  3C59x  Etherlink 
III  Bus  Master  Network  card  for  server  connection  to  the  Naval  Postgraduate  School  hub. 

For  storage,  the  system  has  one  3  1/2  inch  floppy  drive,  an  Iomega  ZIP  drive  for 
100  MB  cartridges,  and  an  Iomega  JAZ  drive  for  1  GB  cartridges.  Additionally,  the 
system  has  one  12X  CD  read  only  device. 

2.  Software 

a.  Server  Operating  System 

The  server  operates  using  Microsoft  NT  Version  4.0  as  implemented 
through  the  Microsoft  BackOffice  2.0  suite.  With  additional  network  cards,  NT  is 
capable  of  supporting  other  computers  in  a  LAN  configuration.  An  NSG  headquartered 
EIS  would  require  this  LAN  option  in  order  to  share  the  maintenance  workload  among  a 
database  administration  team.  A  LAN  was  not  utilized  on  the  prototype. 

NT  set-up  is  easily  accomplished  using  an  install  wizard.  The  wizard 
prompts  the  user  for  information  at  each  step  in  the  installation  process.  Since  the  NSG 
already  possesses  Internet  provider  services,  the  installer  only  needs  a  name  and  IP 


30 


address  for  the  EIS  server  and  an  IP  address  of  the  Internet  provider  for  routing  purposes. 
NT  does  not  need  any  special  configuration  for  the  EIS  to  function  properly.  If  the  server 
has  enough  hard  drive  space,  a  full  load  of  the  operating  system  is  recommended. 

b.  Web  Sever 

The  web  server,  Microsoft  IIS  version  3.0,  is  loaded  in  conjunction  with 
the  NT  BackOffice  suite.  IIS  3.0  has  since  been  replaced  by  version  4.0.  IIS  also  uses  an 
installation  wizard  and  is  pre-configured  to  begin  running  automatically  each  time  the 
server  is  rebooted. 

IIS  contains  many  sample  web  pages  that  load  upon  initial  installation. 
The  server  defaults  to  the  web  page  InetPub/wwwroot/default.htm  as  its  root  page.  Thus, 
if  the  default  is  not  reconfigured,  a  client  who  connects  to  the  server  will  see  this  default 
web  page  and  will  be  able  to  navigate  only  within  Microsoft's  sample  site.  The  simplest 
way  to  change  this  is  to  replace  this  default  file  with  a  new  page.  If  this  file  is  named 
default.htm,  subdirectories  and  links  to  other  pages  in  separate  directories  can  be  inserted 
to  direct  the  client  to  new  areas  within  the  EIS  without  extensive  file  modification. 

To  create  or  modify  HTM  or  HTX  files  (the  files  seen  by  the  user  as  web 
pages),  a  web  editor  such  as  Microsoft  Front  Page  98  must  be  used.  There  are  many 
good  references  available  for  web  site  design  and  creation.  It  is  most  important  to  devise 
a  good  file  structure  naming  convention  to  avoid  confusion.  An  EIS  requires  a  large 
number  of  web  pages  to  effectively  serve  a  client. 

Since  each  IDC  file  contains  SQL  code,  a  text  editor  such  as  Microsoft 
Word  97  is  also  required.  An  explanation  of  SQL  statement  syntax  is  beyond  the  scope 
of  this  thesis.  Again,  there  is  a  great  deal  of  published  material  available  on  the  topic  of 
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SQL  and  manipulating  database  fields.  As  with  the  HTM  and  HTX  files,  a  greater 
number  of  IDC  files  provides  a  finer  granularity  for  interaction  between  user  and 
database.  Approximately  350  separate  IDC,  HTM,  and  HTX  files  were  used  in  the 
creation  of  the  prototype  site.  Fielding  an  actual  site  with  increased  functionality  would 
require  many  more. 

c.  Database  Server 

The  heart  of  the  EIS  is  the  database  server.  The  database  structure  and 
data  reside  in  this  portion  of  the  system.  Although  in  this  project,  the  database  server  and 
the  web  server  were  both  physically  present  on  the  same  machine,  the  ODBC  can  just  as 
easily  connect  nS  to  a  database  server  that  is  located  on  a  separate  computer. 

Microsoft  SQL  Server  6.5  is 

A  relational  database  that's  capable  of  handling  large  amounts  of 
data  and  many  concurrent  users  while  preserving  data  integrity  and 
providing  many  advanced  administration  and  data  distribution 
capabilities.  [Ref  13] 

Like  NT  and  IIS,  it  is  loaded  from  the  BackOffice  suite  through  a  wizard  and  requires  no 
special  configuration! 

Database  systems,  including  this  EIS,  need  a  database  administrator 
(DBA)  to  monitor  the  database.  They  are  charged  with  keeping  the  file  structure  current, 
managing  access  and  user  accounts,  and  optimizing  database  performance.  SQL  Server 
6.5  offers  a  menu  of  powerful  service  managers  for  the  DBA  to  use  to  accomplish  these 
tasks.  The  most  important  of  these  service  managers  and  their  functions  are  listed  in 
Figure  6. 


Service  Name 

Function 

Enterprise  Manager 

Allows  the  DBA  to  create,  destroy, 
manipulate,  backup,  and  replicate 
databases. 

Performance  Manger 

Allows  the  DBA  to  monitor  the  system 
usage  and  execution. 

Security  Manager 

Allows  the  DBA  granular  control  access 
to  individual  databases. 

Service  Manager 

Allows  the  DBA  to  control  operation  of 
the  database  server. 

Web  Assistant 

Gives  the  DBA  a  tool  for  quick  and  easy 
creation  of  database  routines  that  will  run 
on  the  operating  system. 

Figure  6.  Primary  SQ! 

L  Server  6.5  Service  Managers 

In  order  to  create  a  database  using  SQL  Server  6.5,  a  database  device  must 
first  be  created.  This  device  will  partition  SQL  Server  utilities  and  memory  into  distinct 
areas  so  that  each  database  can  be  independent  from  the  next.  Using  the  Enterprise 
Manager,  select  manage  database  devices  to  create  a  device.  There  are  several  devices 
that  are  already  loaded  when  SQL  Server  6.5  is  initially  loaded.  These  devices  contain 
databases  to  serve  as  file  templates  that  the  system  uses  in  its  operations.  These  should 
not  be  modified. 

A  device  is  divided  into  a  log  portion  and  a  data  portion.  The  log  portion 
holds  the  physical  structure  (tables,  query  and  update  routines,  etc.)  while  the  data  section 
holds  only  the  database  data  itself.  The  amount  of  memory  assigned  to  each  of  these 
portions  is  limited  only  by  the  amount  of  available  memory  on  the  database  server  hard 
drive.  For  this  project,  a  100  MB  device  was  created  with  20  MB  allotted  for  the  log 
device  and  80  MB  allotted  for  data. 

The  next  step  is  to  create  a  database  to  reside  on  that  device.  Using  the 
Enterprise  Manager,  select  manage  databases  to  create  a  new  database.  The  database 
server  now  recognizes  the  new  database  although  it  has  no  structure  or  data. 
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Next,  the  database  must  be  supplied  with  a  relational  structure.  The 
Enterprise  Manager  also  contains  tools  for  table  creation  and  maintenance.  Creating  a 
table  involves  naming  the  table,  dividing  it  into  the  desired  fields,  assigning  data  types  to 
these  fields,  and  then  declaring  the  appropriate  relationships  between  various  tables 
through  the  manage  tables  icon.  Only  after  a  database  schema  has  been  assigned  to  a 
database  may  it  be  populated  with  data. 

Unfortunately,  SQL  Server  6.5  is  a  back-end  tool  only.  This  means  that 
another  application  (such  as  Microsoft  Access  or  the  IIS  interface  of  the  EIS)  must  be 
used  in  order  to  insert  data  into  the  database.  There  is  no  convenient  way  to  directly  enter 
data  using  SQL  Server  6.5.  Furthermore,  the  tools  supplied  with  the  Enterprise  Manager 
to  manipulate  the  structure  of  a  database  are  useful  when  a  database  already  exists  but 
very  cumbersome  when  used  to  create  a  new  one. 

Microsoft  Access  is  a  popular  stand-alone  relational  DBMS  in  wide  use 
throughout  the  NSG.  The  DoN  and  civilian  corporations  in  past  years  have  cached  much 
valuable  data  using  this  DBMS.  One  if  its  best  features  is  a  wide  variety  of  graphical 
tools  that  empower  the  database  designer  to  easily  construct  a  database.  One  does  not 
need  to  be  proficient  at  SQL  in  order  to  create  the  tables,  queries  and  update  routines 
required  of  a  good  database. 

In  order  to  provide  the  user  a  way  to  retain  existing  Access  data  and  gain 
the  increased  availability,  functionality,  and  security  of  SQL  Server,  Microsoft  created  a 
tool  called  Microsoft  Upsize.  Upsize  copies  any  Access  database  and  its  data,  and  then 
converts  it  to  SQL  Server  format.  It  then  transfers  this  package  directly  to  any  available 
SQL  Server  database  indicated  by  the  user.  Upsize  supplies  the  capability  to  employ  the 


34 


user-friendly  tools  of  Access  but  retain  the  power  of  the  SQL  server.  In  addition,  the 
NSG  community  can  use  Upsize  to  facilitate  the  entry  of  necessary  legacy  data  into  the 
EIS.  Once  installed.  Upsize  is  implemented  through  the  tools  section  in  Access.  Upsize 
can  be  downloaded  at  no  cost  (Microsoft  Home  Page). 

d.  ODBC  Path 

The  final  step  in  implementing  the  EIS  is  to  establish  the  ODBC 
connection.  Both  IIS  and  Upsize  require  an  ODBC  path  name  in  order  to  connect  to  SQL 
Server.  The  ODBC  path  is  created  using  Windows  NT  utilities  contained  within  the 
control  panel.  The  SQL  Server  driver  automatically  loaded  when  NT  version  4.0  is 
installed.  It  is  important  to  identify  the  path  name,  the  name  of  the  server  with  which  to 
connect,  and  the  name  of  the  desired  server  database  when  creating  an  ODBC  path.  Once 
instantiated,  an  ODBC  path  is  a  permanent  reference  until  deleted. 

C.  CLIENT  REQUIREMENTS 

Any  client  machine  with  a  modem  or  direct  connection  to  an  Internet  provider  is 
capable  of  connecting  to  the  EIS  server.  No  other  hardware  is  required.  The  client  must 
use  a  web  browser  to  communicate  with  the  database.  Compatibility  of  Microsoft 
products  between  client  and  server  is  not  necessary.  Both  Microsoft  Internet  Explorer 
and  Netscape  Navigator  are  prevalent  throughout  the  NSG. 
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V.  DATABASE  SCHEMA 


A.  OVERVIEW 

The  essence  of  any  relational  database  remains  the  number  and  type  of  fields 
contained  within  individual  tables.  Table  fields  provide  a  framework  for  the  DBMS  to 
know  what  data  to  store  and  how  much  memory  to  reserve  for  each  field.  A  listing  of  the 
separate  fields  in  each  table  of  the  database  and  the  manner  in  which  these  are  related  to 
one  other  is  known  as  the  database  schema.  The  database  schema  delineates  how  the  data 
is  to  be  preserved  by  the  DBMS.  A  proper  database  schema  provides  the  user  a  powerful 
framework  within  which  to  store  and  retrieve  data  in  a  logical  and  useful  manner. 

Each  field  in  a  table  must  be  assigned  to  a  specific  data  type.  Data  types  allow  the 
DBMS  to  optimize  storage  space  by  allocating  a  specific  amount  of  memory  for  each 
field  of  data.  Some  data  types  even  allow  the  database  engineer  to  specify  the  maximum 
size  of  the  field.  This  feature  allows  the  database  designer  to  improve  memory 
availability  and  configure  a  system  for  maximum  performance.  The  SQL  server  6.5  data 
types  used  in  the  EIS  database  schema  are: 

1 .  Datetime  -  A  block  of  integers  consisting  of  a  six-digit  date  followed  by 

an  eight-digit  time 

2.  Float  -  A  decimal  point  number 

3  Image  -  An  item  that  will  be  displayed  as  a  picture 

4.  Int-  Integers  (no  decimal  point)  only 

5.  Money  -  A  number  with  two  decimal  places 

6.  Text  -  Characters  only 

7.  Varchar  -  Any  integer  or  character  combination 
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In  contrast  to  data  types,  database  relationships  show  how  data  fields  in  one  table 
are  linked  to  other  data  fields  in  separate  tables.  Linked  fields  must  always  be  of  the 
same  data  t5^e  and  size.  A  relationship  constraint  shows  all  possible  combinations 
between  any  related  fields.  A  relationship  may  be  classified  as  one-to-one  (1— >1)  or  one- 
to-many  (l-^oo).  In  a  one-to-one  relationship,  each  field  value  is  unique  and  may  appear 
only  once  in  each  of  the  indicated  tables.  In  a  one-to-many  relationship,  the  first  field 
value  may  appear  only  once  in  the  first  table  but  the  second  may  appear  multiple  times  in 
the  second  table.  A  many-to-one  (oo->l)  designation  is  identical  to  one-to  many  but  in 
reverse  order. 

To  simplify  a  relationship  description  in  this  chapter,  the  standard  SQL  "dot- 
notation"  is  used.  In  this  nomenclature,  the  name  of  the  desired  table  appears 
immediately  before  a  period  while  the  name  of  the  indicated  field  is  displayed  afi:er. 
Thus,  "TableA.Fieldl"  indicates  Field  1  of  Table  A. 

This  EIS  database  schema  consists  of  33  distinct  tables  comprised  of  253  fields 
and  68  separate  relationships.  For  efficiency,  each  of  these  tables  has  been  placed  into 
one  of  the  six  basic  functional  groups  depicted  in  Figure  7. 

Each  table  has  been  assigned  to  a  differing  functional  group  in  order  to  maximize 
personnel  resources  at  individual  commands.  Though  overlapping  somewhat  in 
functionality,  each  category  group  represents  a  separate  NSG  working  specialty  that  is 
defined  by  a  unique  set  of  NSG  data  keeping  operations.  At  NSG  sites,  individuals 
working  in  these  sub-specialties  have  different  ratings,  have  undergone  different  job 
training,  and  are  usually  grouped  into  separate  departments  and  divisions  with  different 
chains-of-command. 
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■  •  1 .  V  .■  :  v;:.- jv:;::;;  :•  •  - 

■ '  .  ■ '  s  •  •  • ' '  V ; , :  V  ■  W  '■ :%  "  ■  - 

Headquarters 

Maintenance 

Operations  &  Training 

1.  AothodzatLon  of 

2.  Billet  0ccii])at]Oft 

3.  t)aty  type  DeKcripIloo 

4.  Fiscal  Authorization 

5.  Mssloti  Area  !>escrit^on 

6.  >3£C  Descriptian 

7.  FMS  Description 

8^,  Position  Description 

9.  Purchase  Cathodes 

10.  Stock  Item  Description 

11.  TAD  Master 

12.  Track  Dictionaty 

13.  TrainingDescription 

1.  Maintenance 

1:1,  ^•Gretw;X;|:' 

1 

Figure  7.  NSG  Functional  Groups  and  their  EIS  Tables 


Each  table  is  discussed  individually  in  detail  in  the  following  section.  A  brief 
description  of  the  group  itself  is  first  given  followed  by  a  schema  for  each  table  in  the 
group.  A  brief  description  of  the  table's  purpose  is  also  provided  followed  by  all  of  its 
fields,  data  types,  relationships,  and  relationship  constraints.  Data  type  sizes  for  the 
varchar  type  have  been  omitted  for  clarity.  All  table  names  are  given  in  italicized  script 
while  table  key  fields  (if  any)  are  listed  in  boldface.  A  blank  space  in  the  "links  to" 
column  indicates  that  a  field  has  no  direct  correspondence  to  any  other  table  field. 

1.  Administrative 

The  Administrative  element  of  a  NSG  command  performs  all  unit  level  clerical 
duties.  Its  primary  function  is  to  process  and  maintain  personal  and  military  information 
about  each  command  member  and  their  families. 
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Typical  tasks  assigned  to  this  group  include  generating  travel  orders,  maintaining 
personnel  records  on  job  performance  and  occupational  specialties,  maintaining  statistics 
on  temporary  duty  assignments  and  days  worked,  processing  incoming  and  outgoing 
command  personnel,  and  maintaining  command  directories.  Eight  EIS  basic  tables  have 
been  constructed  to  contain  the  data  generated  by  the  administrative  functional  group  in 
the  sample  EIS.  Each  is  described  in  Figure  8. 


Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

Binnacle  List 
Duty 

absences  due 
to  illness  or 

ininrv 

Command  ID 

Varchar 

Command  Information.  Command  ID 

C!0->-l 

Control  Number 

Varchar 

End  Date 

Datetime 

Social  Security  Number 

Varchar 

Sailor.  Social  Security  Number 

00->l 

Start  Date 

Datetime 

EAOSData 

Departed  Service 

Datetime 

Individual 
End  of 

Active 
Obligated 
Service  dates 

Reenlistment  Date 

Datetime 

Reenlistment  Period 

Int 

Retired 

Datetime 

Social  Security  Number 

Varchar 

Sailor.  Social  Security  Number 

O0->1 

Family 

Birthdate 

Datetime 

Members 

Conunand 

Family  Member  Social 
Security 

Varchar 

family 

member  data 

Name 

Varchar 

Sailor  Social  Security 
Number 

Varchar 

Sailor.  Social  Security  Number 

00-^1 

Sex 

Varchar 

Leave 

Duty 

absence  due 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00^1 

Date  of  Departure 

Datetime 

Date  of  Return 

Datetime 

to  vacation 

Leave  Control  Number 

Varchar 

Social  Security  Number 

Varchar 

Sailor.  Social  Security  Number 

00^1 

Type  of  Leave 

Varchar 

PRTData 
Individual 
scores  on  the 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00->l 

Height 

Varchar 

PRT  Date 

Datetime 

semi-annual 

PRT  Identifier 

Varchar 

Navy 

nt  1  ~ 

Pushups 

Varchar 

i^nysicai 

Rim  Time 

Varchar 

JEN. VClUJ.  lie  3  IS 

XpQt 

Situps 

Varchar 

X  wot 

Social  Security  Number 

Varchar 

Sailor.  Social  Security  Number 

00^1 

Status 

Varchar 

Weight 

Varchar 

Figure  8.  Administrative  Group  Tables 
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Table  and 
Purpose 
Sailor 
Personal 
data  about 
command 
members 


Field  Name 
Address 


Birthdate _ 

Cir 


Country _ 

Date  of  Rank 


First  Name _ 

Homephone 


Homestate _ 

Hometown 


Last  Name 


Last  Updated _ 

Middle  Name 


Paygrade _ 

Photograph 


Postal  Code _ 

Primary  NEC/Designator 


Rank/Rate _ 

Secondary  NEC 


Service  Entry  Date _ 

Sex 


Varchar 


Datetime 

Varchar 


Varchar 


Datetime 


Varchar 


Varchar 


Varchar 

Varchar 


Varchar 


Datetime 


Varchar 


e 


Varchar 

Varchar 


Varchar 


Varchar 


Datetime 


Varchar 


NEC  Description.NEC  Designator 


NEC  Description.NEC  Designator 


Air  Crews.  Social  Security  Number 

l->oo 

Billet  Occupation.  Social  Security  Number 

1^00 

Biimacle  List.  Social  Security  Number 

1^00 

DepartmentDepartment  Chief  SSN 
Department-Department  Head  SSN 

l~»oo 

1->00 

Division.Division  Chief  SSN 
Division.Division  OfiScer  SSN 

1^00 

1^00 

EAOS  Data.  Social  Security  Number 

1->CX) 

Expenses.Purchaser  SSN 

1— >00 

Family  Members.  Sailor  Social  Security 
Number 

1^00 

Leave.  Social  Security  Number 

1->00 

Maintenance.Person 

1— >00 

Properties  Listing.Inventoiy 
Properties  Listing.Purchaser 
Properties  Listing.  Subcustodied 

PRT  Data.  Social  Security  Number 


Qualification  and  Training.  Sailor  Social 
Security  Number 


Sea  Crews.  Social  Security  Number 
Spouses.  Sailor  Social  Security  Number 


TAD.Member  Social  Security  Number 


Tertiary  NEC _ Varchar  NEC  Description.NEC  Designator 

Warfare  Device  1 _ Varchar 


Warfare  Device  2 _ 

Warfare  Device  3 


Figure  8.  Administrative  Group  Tables  (cont.) 


Varchar 
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Table  and 
Purpose 

Type 

Links  to: 

Type 

Spouses 
Data  about 
command  a 
member's 
spouse 

Date  Updated 

Datetime 

Sailor  Social  Security 
Number 

Varchar 

Sailor.  Social  Security  Number 

1^1 

Spouse  Date  of  Birth 

Datetime 

Spouse  Gender 

Varchar 

Spouse  Name 

Varchar 

Spouse  Social  Security 
Number 

Varchar 

TAD 

Temporary 
Assigned 
Duty  data 

Date  of  Arrival  at 
Destination 

Datetime 

Date  of  Departure 

Datetime 

Date  of  Departure  from 
Destination 

Datetime 

Departed  from  City 

Varchar 

Departed  from 

Command  Name 

Varchar 

Departed  from  Country 

Varchar 

Destination  City 

Varchar 

Destination  Command 

Varchar 

Destination  Country 

Varchar 

Liquidated 

Varchar 

Liquidation  Date 

Datetime 

Member  Command  ID 

Varchar 

Command  Information.  Command  ID 

00-^1 

Member  Social  Security 
Number 

Varchar 

Sailor.  Social  Security  Number 

00-^1 

Segment  Number 

Varchar 

TAD  Cost.  Segment  Number 

1-»1 

TAD  ID  Code 

Varchar 

TAD  Master.  Conference  Training  ID  Code 

00-~>l 

Tango  Number 

Varchar 

Figure  8.  Administrative  Group  Tables  (cont.) 


2.  Budget  and  Supply 

The  Budget  and  Supply  element  of  a  NSG  command  is  responsible  for  tracking 
command  expenditures  and  handling  all  the  supply  matters  for  the  individual  unit.  Its 
duties  encompass  balancing  all  individual  budgets,  purchasing,  providing  inventories  of 
command  minor  properties,  liquidating  travel  claims,  ordering  equipment  and  routine 
supplies,  and  accounting  for  all  ongoing  command  expenditures  such  as  electricity  and 
service  contracts.  The  three  EIS  tables  associated  with  the  budget  and  supply  functional 
group  are  described  below  in  Figure  9. 
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Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

Expenses 

Routine 

command 

expenses 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00— >1 

Purchase  Category 

Varchar 

Purchase  Categories.Purchase  Category 

00^1 

Purchase  Control 
Number 

Varchar 

Purchase  Date 

Datetime 

Varchar 

Sailor.  Social  Security  Number 

00-^1 

Quantity 

Int 

Stock  Number 

Varchar 

Stock  Item  Descriptions.  Stock  Number 

C30-->1 

Total  Price 

Money 

Unit  Price 

Properties 

Listing 

Command  minor 

property 

purchases 

Conunand  ID 

Varchar 

Command  Information.  Command  ID 

00->l 

Datetime 

Datetime 

Inventory 

Varchar 

Sailor.  Social  Security  Number 

00-)-l 

Last  Inventoiy 

Date 

Datetime 

Price 

Money 

Property 

Description 

Varchar 

Property  ID 

Varchar 

Maintenance.Property  ID 

l->oo 

Purchase  Category 

Varchar 

Purchase  Categories.Purchase  Category 

00->l 

Purchaser 

Varchar 

Sailor.  Social  Security  Number 

oo->l 

Subcustodied 

Varchar 

Sailor.  Social  Security  Number 

00->1 

TAD  Cost 
Command  travel 
expenses 

Billeting  Cost 

Money 

Liquidated 

Varchar 

Liquidation  Date 

Datetime 

Miscellaneous 

Expense 

Money 

Mode  of  Travel 

Varchar 

Purchase  Category 

Varchar 

Purchase  Categories.Purchase  Category 

00->>1 

Segment  Number 

Varchar 

TAD.  Segment  Number 

1^1 

Tango  Number 

Varchar 

Total  Cost 

Money 

Travel  Cost 

Money 

Type  of  Billeting 

Varchar 

Figure  9.  Budget  and  Supply  Group  Tables 


3.  Command 

The  NSG  command  element  consists  of  executive  personnel  who  oversee  all  the 
functions  of  a  unit.  Though  not  usually  responsible  for  direct  data  entry,  decisions  about 
how  the  command  is  to  be  structured  and  how  workloads  are  to  be  shared  must  be  made 
at  this  level.  The  three  EIS  tables  associated  with  the  command  functional  group  are 
described  below  in  Figure  10. 
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Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

Command 

Information 

Address 

Varchar 

City 

Varchar 

Unit  level 
command  data 

Command  ID 

Varchar 

Air  Crews.  Member  Parent  Command 
ID 

l->cx) 

Authorization  of  Billets.  Command  ID 

1^00 

Billet  Occupation.  Command  ID 

l-~>00 

Binnacle  List.Command  ID 

1^00 

Department.  Command  ID 

l’->00 

Division.  Command  ID 

l--»oo 

Expenses.  Command  ID 

1^00 

Fiscal  Authorization.  Command  ID 

l-»00 

Leave.  Command  ID 

l->00 

Maintenance.  Command  ID 

1^00 

Properties  Listing.  Command  ID 

I-^oo 

PRT  Data.  Command  ID 

1^00 

Qualification  and  Training.Command 
ID 

1“>00 

Sea  Crews.Member  Parent  Command 
ID 

l->00 

TAD.Member  Conunand  ID 

l->00 

Command  Name 

Varchar 

Country 

Varchar 

Email 

Varchar 

Notes 

Varchar 

Photograph 

Image 

Postal  Code 

Varchar 

Region 

Varchar 

State  or  Province 

Varchar 

Work  Phone 

Varchar 

Department 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00->l 

Data  about 
departments 

Department  Chief  SSN 

Varchar 

Sailor.  Social  Security  Number 

00->l 

within  a 

Department  Head  SSN 

Varchar 

Sailor.  Social  Security  Number 

00-^1 

command 

Department  ID 

Varchar 

Division.Department  ID 

1— >oo 

Maintenance.Department  ID 

l->00 

Email 

Varchar 

Telephone 

Varchar 

Title 

Varchar 

Division 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00->1 

Data  about 

Department  ID 

Varchar 

DepartmentDepartment  ID 

00-^1 

divisions  within 

Division  Chief  SSN 

Varchar 

Sailor.  Social  Security  Number 

oo->l 

a  department 

Division  ID 

Varchar 

Maintenance.Division  ID 

1-^00 

Division  Officer  SSN 

Varchar 

Sailor.  Social  Security  Number 

00-^1 

Email 

Varchar 

Telephone 

Varchar 

Tide 

Varchar 

Figure  10.  Command  Group  Tables 
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4.  Headquarters 

The  NSG  Headquarters  unit  supervises  all  claimancy  operations.  Their  primary 
responsibility  is  to  set  policy  and  conduct  oversight  of  the  community  at  large.  The  EIS 
tables  associated  with  NSG  headquarters  serve  primarily  to  ensure  that  uniform  sets  of 
data  are  available  to  individual  commands.  Subsequent  tables  in  other  functional  groups 
directly  reference  each  table  in  this  group.  For  example,  an  operator  in  the  administrative 
group  may  assign  a  Navy  Enlisted  Classification  code  (NEC)  to  a  sailor.  This  value  must 
correspond  to  an  appropriate  entry  that  has  been  input  into  the  database  by  a  member  of 
the  headquarters  staff.  Referential  integrity  constraints  set  by  the  database  schema  ensure 
that  incongruous  data  will  not  be  accepted. 

Enabling  one  central  authority  to  set  uniform  data  parameters  is  crucial  to  EIS 
integrity.  As  with  the  command  group,  NSG  headquarters  retains  some  direct  data  input 
responsibilities  that  may  not  be  delegated  to  the  command  level.  The  thirteen  tables 
associated  with  headquarters  functional  group  are  described  below  in  Figure  1 1 . 


Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

A  uthorization  o f 
Billets 

Sets  command 
billets 

Billet  ID  Code 

Varchar 

Billet  Occupation.Billet  ID  Code 

l->oo 

Command  ID 

Varchar 

Command  Informatioa  Command  ID 

00->l 

Date  of  Authorization 

Datetime 

Date  of  Last  Update 

Datetime 

Description 

Varchar 

Fill  Priority 

Int 

Maximum  Paygrade 

Varchar 

Minimum  Paygrade 

Varchar 

NEC/Designator  1 

Varchar 

NEC  Description.NEC/Designator 

00->l 

NEC/Designator  2 

Varchar 

NEC  Description.NEC/Designator 

00-^1 

NEC/Designator  3 

Varchar 

NEC  Description.NECyDesignator 

00->l 

Other  Special 
Qualifications 

Varchar 

Type  Duty 

Int 

Duty  Type  Description.Type  Duty 

ao-^l 

UIC 

Int 

Warfare  Device 
Required 

Varchar 

Figure  11.  Headquarters  Group  Tables 
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Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

Billet  Occupation 
Assigns 
individuals  to 
command  billets 

Actual  Date  of 
Departure 

Datetime 

Billet  ID  Code 

Varchar 

Authorization  of  Billets.Billet  ID 

Code 

00-<->l 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00->l 

Date  Assigned 

Datetime 

Date  of  Arrival 

Datetime 

Orders  Number 

Varchar 

Varchar 

Sailor.  Social  Security  Number 

00— >1 

Tour  Length 

Float 

Duty  Type 
Description 

Lists  NSG  duty 
types _ 

Type  Duty 

Varchar 

Authorization  of  Billets.Type  Duty 

l->00 

Description 

Varchar 

Fiscal 

Authorization 

Sets  command 
budgets 

Allotment 

Money 

Authorization 

Number 

Varchar 

Command  ID 

Varchar 

Command  Information.  Command  ID 

00->1 

Date  of  Authorization 

Datetime 

Fiscal  Year 

Varchar 

Purchase  Category 

Varchar 

Purchase  Categories. Purchase 

Category 

00->1 

Quarter 

Varchar 

Mission  Area 
Description 

Sets  operational 
areas 

Description 

Varchar 

Mission  Area  D) 

■ 

Flight  Mission.Mission  Area  ID 

1-^00 

Sea  MissioaMission  Area  ID 

1— >00 

NEC  Description 
Sets  Navy 

Enlisted 
Classification 
Codes job 
specialties  for  the 
community 

Description 

NEC  Designator 

Varchar 

Authorization  of 
Billets.NEC/Designator  I 

Authorization  of 
Billets.NEC/Designator  1 

Authorization  of 
Billets.NEC/Designator  1 

Sailor.Primary  NEC  Designator 

Sailor.  Secondary  NEC 

Sailor.Tertiaiy  l^C 

1-^00 

1— >00 

l*~>O0 

1— >00 
1->00 

1— >00 

Other  Special 
Qualifications 

Varchar 

Source  Rating  1 

Varchar 

Source  Rating  2 

Varchar 

Source  Rating  3 

Varchar 

Smuce  Rating  4 

Varchar 

Source  Rating  5 

Varchar 

- — - 

Technical  Advisor 

Varchar 

Figure  1 1 .  Headquarters  Group  Tables  (cont.) 
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Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

PMS  Description 
Sets  maintenance 
tasks  for  the 
Preventative 
Maintenance 
System 

Description 

Varchar 

Periodicity 

Int 

PMS  Item  Number 

Varchar 

Maintenance.PMS  Item  Number 

I->00 

Position 

Description 

Defines 

operational  duty 
positions 

Position 

Varchar 

Air  Crews.Position 

I ->00 

Sea  Crews.Position 

1^00 

Position  Description 

Varchar 

Purchase 

Categories 

Sets  budget  line 
items  for 
command 
purchases 

Description 

Varchar 

Purchase  Category 

Varchar 

Expenses.Purchase  Category 

I— >oo 

Fiscal  Authorization.Purchase 

Category 

I->00 

Properties  Listing.Purchase  Category 

I->00 

TAD  Cost.Purchase  Category 

I— >00 

Stock  Item 
Descriptions 
Assigns  numbers 
to  stock  items 

■  IIIIMI  1  lIMM 

Varchar 

Description 

Varchar 

Stock  Number 

Varchar 

Expenses.  Stock  Number 

I— >00 

TAD  Master 

List  of  all 
Temporaiy 
Assigned  Duty 
(TAD)  events 

Conference 

Training  ID  Code 

Varchar 

TAD.TAD  ID  Code 

I ->00 

Periodicity 

Int 

Reference 

Varchar 

Schedule  Date 

Datetime 

Title 

Varchar 

Track  Dictionary 
Lists  airborne 
operation  tracks 

Cognizant  Authority 

Varchar 

Track  ID 

Varchar 

Flight  Mission.Track  ID 

I— >00 

Training 

Description 

Lists  training  and 
job  qualification 
requirements 

Cognizant  Authority 

Varchar 

Reference 

Varchar 

Requal  Period 

Float 

Training  Description 

Varchar 

Training  ID 

Number 

Varchar 

Qualification  and  Training.Training 

ID  Number 

I -^00 

Figure  11.  Headquarters  Group  Tables  (cont.) 


5.  Maintenance 

The  NSG  command  maintenance  element  is  charged  with  performing  both 
emergency  and  regularly  scheduled  preventative  maintenance  on  all  the  equipment  and 
facilities  located  at  the  individual  unit.  This  group  is  also  tasked  with  providing  work 
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logs  for  all  maintenance  conducted.  Only  one  EIS  table  is  associated  with  the 
maintenance  functional  group.  It  is  listed  below  in  Figure  12. 


Table  and 
Purpose 

Field  Name 

Type 

Links  to: 

Type 

Maintenance 

Records  of  all 
command 
maintenance 
preformed 

Command  ID 

Varchar 

Command  Information.  Conunand  ID 

00^1 

Date  Conducted 

Datetime 

Department  ID 

Varchar 

Department.Department  ID 

00->l 

Division  ID 

Varchar 

DepartmentDepartment  ED 

00~>1 

Emergency 

Description 

Varchar 

Hours  on  Job 

Float 

Item  ID 

Varchar 

Properties  Listing.Property  ID 

00->l 

Maintenance 

Number 

Varchar 

Person 

Varchar 

Sailor.  Social  Security  Number 

00~>1 

PMS  Item 

Number 

Varchar 

PMS  Description.PMS  Item  Number 

00-^1 

Remaint 

Varchar 

Varchar 

Figure  12.  Maintenance  Group  Table 


6.  Operations  and  Training 

The  NSG  operations  and  training  functional  group  is  responsible  for  conducting 
cryptologic  operations  and  ensuring  current  and  complete  professional  training  of  all 
command  personnel.  The  operations  group  constitutes  a  major  portion  of  a  NSG 
command  and  encompasses  all  air,  surface,  and  submarine  operations  that  may  deploy  to 
any  point  of  the  globe. 

The  training  group  is  charged  with  both  initial  and  follow-on  job  skills  training  as 
well  as  recording  completed  training  for  both  the  individual  and  the  command  as  a  whole. 
Although  at  many  individual  commands  these  two  responsibilities  are  delegated  to 
separate  departments,  they  have  been  combined  here  for  simplicity.  The  five  EIS  tables 
associated  with  the  operations  and  training  fiinctional  group  are  listed  below  in  Figure  13. 
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Table  and 
Purpose 


Air  Crews 
Records  all 
crewmembers 
for  a  flight 
mission 


Flight  Mission 
Records  data 
on  flight 
missions 


Qualification 

and  Training 

Records 

individual 

training 

completed 


Sea  Crews 
Records  all 
crewmembers 
of  a  sea-based 
mission 


Flight  Mission  Number  Varchar 
Flight  Serial  Number  Varchar 


Member  Parent 

Command  ID _ 

Position 


Social  Security  Number 


Date  Time  of  Landing 
Date  Time  of  Takeoff 


Duration 


Exercise  Name _ 

Flight  Mission 
Number 


Mission  Area  ID 


Platform  Number 


Platform  Type 


Squadron 


Squadron  Crew 


Staged  From  Base _ 

Staged  From  City _ 

Staged  From  Country 


Track  ID _  Varchar 

Type  of  Mission _ Varchar 

Conmiand  ID  pvarchar 


Completion  Date _ 

Requal 


Sailor  Social  Security  Varchar 

Number _ 

Training  ID  Number  Varchar 


Member  Parent  Varchar 

Command  ID _ 

Position  Varchar 


Sea  Mission  Number  Varchar 


Sea  Serial  Number 
Social  Security  Number 


Date  of  Mission 


Varchar 


Da 

Da 


Float 


Varchar 

Varchar 


Varchar 


Varchar 


Varchar 


Varchar 

Varchar 


Varchar 


ivsmrmi 


Flight  Mission.Flight  Mission  Number 


Command  Information.  Command  ID 
Position  Description.Position 


Sailor.  Social  Security  Number 


Air  Crews.Flight  Mission  Number 


Mission  Area  Description.Mission  Area 
ID 


Track  Dictionary.Track  ID 

oo->l 

Command  Information.  Command  ID 

00^1 

Varchar  I  Sailor.  Sailor  Social  Security  Number 


Training  Description.Training  ID 
Number 


Command  Information,  Command  ID 
Position  Description.Position 


Sea  Mission.  Sea  Mission  Number 


Sailor.  Social  Security  Number 


Mission  Area  Description.Mission  Area 
ID 
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VI.  SAMPLE  SERVER  EIS  HEIRARCHY 


A.  INTRODUCTION 

1.  Sample  Site  Location 

At  the  onset  of  this  research,  the  hardware  described  in  section  B1  chapter  IV  was 
identified  for  use.  After  initial  hardware  checks  were  concluded,  the  following  steps 
were  taken  to  establish  the  sample  EIS: 

1.  The  computer's  hard  drive  was  reformatted  and  all  NT  operating  system 
and  database  application  software  was  loaded. 

2.  The  system  was  connected  to  the  Naval  Postgraduate  School  Computer 
Science  "1-net"  LAN.  This  LAN  is  directly  connected  to  the  Internet 
through  in-house  hub  facilities. 

3.  The  database  schema  was  created  in  Microsoft  Access,  and  the  database 
was  populated  with  sample  data. 

4.  The  Access  database  was  upsized  to  SQL  Server  6.5. 

5.  The  necessary  HTM,  HTX,  and  IDC  files  were  created  and  made  available 
to  IIS  for  publishing  to  the  Internet. 

At  the  time  of  this  writing,  the  sample  NSG  EIS  can  be  accessed  through  URL 
[http://cryptologist.cs.nps.navy.mil  or  IP  address  131.120.1.226]. 

2.  Accessing  Sample  Site  Data 

Access  to  the  sample  EIS  has  been  divided  into  seven  main  web  pages  that  adhere 
as  closely  as  possible  to  their  corresponding  NSG  functional  areas.  An  additional  general 
information  group  with  no  input  responsibility  has  been  added  for  general  access.  Each 
web  page  contains  those  operations  that  would  be  performed  by  members  of  the 
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particular  functional  group  described  in  Chapter  V.  A  general  roadmap  for  navigating 
through  the  sample  site  is  provided  in  Figure  14. 

A  user  navigates  to  the  desired  page  through  a  series  of  hyperlink  selections. 
Once  at  the  appropriate  web  page,  the  user  is  free  to  perform  the  desired  data  operation. 
Each  of  the  specific  data  operations  contained  within  these  functional  group  main  pages 
is  examined  in  detail  in  the  following  sections. 


Figure  14.  EIS  Sample  Site  Roadmap 


B.  EIS  DATA  OPERATIONS 

Each  functional  group  main  page  is  separated  into  a  combination  of  insert,  update, 
and  query  operations.  SQL  server  6.5  allows  a  user  to  manipulate  the  database  primarily 
through  inserting  data,  updating  data,  and  performing  queries  on  data.  Once  the  user  has 
gained  access  to  a  certain  main  page,  he  or  she  may  perform  any  of  the  operations  that 
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have  been  constructed  and  placed  on  that  page  by  the  database  developer.  Access  to 
particular  web  pages  is  discussed  in  detail  in  the  next  chapter. 

Data  insertion  and  update  is  accomplished  through  the  use  of  computerized  forms 
that  are  presented  by  IIS  to  the  individual  user.  Each  form  contains  separate  data  entry 
blocks  necessary  for  a  specific  operation.  After  all  appropriate  data  has  been  entered  into 
the  form,  the  user  submits  the  form  to  the  database  by  selecting  a  "submit"  button.  The 
submit  routine  then  commits  the  data  to  the  database.  After  submission,  the  data  is 
permanently  inserted  or  updated  to  the  EIS. 

Following  submission,  the  user  is  returned  to  a  web  page  from  which  additional 
site  navigation  decisions  may  be  made.  If  the  data  entered  does  not  meet  preset 
tolerances,  all  of  the  data  submitted  is  rejected.  The  database  roll  back  to  its  previous 
state,  an  error  is  logged  to  the  NT  operating  system,  and  a  message  is  returned  to  the  user. 
From  this  point,  the  user  has  the  single  option  of  using  the  web  browser  to  back  out  of  the 
error  message  page  to  the  previous  form  page.  Ultimately,  the  user  may  either  correct  the 
error  and  resubmit  the  form  or  move  to  a  new  page. 

The  most  common  query  requires  some  input  from  the  user.  As  with  the 
insert/update  operation,  when  a  query's  hyperlink  is  selected,  a  form  is  returned  to  the 
user.  The  user  completes  the  form  and  submits  it  to  the  database.  However,  unlike 
inserts  and  updates,  a  query  has  no  correct  or  incorrect  response  from  the  database.  An 
answer  is  always  returned  by  the  system.  If  the  user  has  submitted  data  outside  the 
tolerances  of  the  database,  it  will  simply  return  a  negative  answer.  All  values  matching 
all  parameters  input  by  the  user  will  always  be  returned. 
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It  is  possible  for  the  database  designer  to  construct  a  query  that  requires  no  user 
input.  For  this  type  of  query,  the  SQL  statement  contains  all  the  data  parameters 
necessary  to  return  results.  In  this  case,  the  user  simply  clicks  the  hyperlink  with  the 
name  of  the  query.  The  hyperlink  calls  the  corresponding  SQL  statement  that  performs  a 
select  operation  on  the  database  and  the  results  are  returned  to  the  user. 

Most  often,  multiple  inserts,  updates,  and  queries  are  combined  within  one 
operation.  The  nature  of  these  operations  is  purposefully  transparent  to  the  user.  The 
average  user  should  not  care  how  the  EIS  performs  its  job,  only  that  it  does  accurately 
and  efficiently.  In  addition,  SQL  provides  operations  that  change  the  form  of  the  data 
without  changing  the  data  content  itself  This  implementation  of  the  EIS  makes  foil  use 
of  these  utility  functions.  Data  is  routinely  converted  from  one  input  form  for  storage  in 
the  database  and  converted  back  for  display  to  the  user  without  the  user's  knowledge. 
Such  data  conversions  are  necessary  in  order  to  maximize  utility  within  the  EIS.  Samples 
of  some  of  the  various  insert,  update,  and  query  operations  contained  in  EIS  IDC  files  are 
provided  in  Appendix  B.  In  addition,  examples  of  the  computerized  forms  and  data 
return  pages  in  the  form  of  HTM  and  HTX  files  have  also  been  made  available. 

The  remainder  of  this  section  outlines  the  operations  available  within  each  of  the 
main  web  pages.  Figures  15-21  give  a  complete  listing  of  these  operations  sorted 
alphabetically  by  functional  group  name. 
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1 


Administration 


Hyperlink  name 

Function 

SQL 

operation 

Affected  Tables 

Binnacle  List  Entry 

Adds  a  sick  list  entry  to  a  specified 
conunand 

Insert 

Binnacle  List 

Family  Members 

Lists  all  family  members  of  a  specified 
command  member 

Select 

Family  Members 

Sailor 

Initial  Travel  Claim 

Adds  initial  command  travel  claim  data 

Insert 

TAD 

TAD  Cost 

Leave  Entry 

Adds  an  individual  leave  entry 

Insert 

Leave 

Leave  Report 

Lists  all  leave  information  on  a 
specified  command  member 

Select 

Losses  List 

Lists  all  command  members  scheduled 
to  rotate  from  a  specified  command 
within  six  months  of  today's  date 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Mailing  List 

Lists  the  addresses  of  all  members  of  a 
specified  command 

Select 

Billet  Occupation 
Command  Information 
Sailor 

New  Family 

Member 

Adds  a  family  member  to  the 
household  of  a  specified  command 
member 

Insert 

Family  Members 

New  NEC 

Adds  a  new  NEC  to  a  selected  sailor 

Select 

Update 

Sailor 

New  Spouse 

Adds  a  spouse  to  a  specified  command 
member 

Insert 

Spouses 

New  Warfare 

Device 

Adds  a  new  warfare  device  to  a 
specified  command  member 

Select 

Update 

Sailor 

Personal  Days 
Deployed 

Calculates  the  number  of  days  a 
specified  command  member  is 
deployed  from  a  selected  command 
over  a  given  timeframe 

Select 

Billet  Occupation 
Command  Information 
Sailor 

TAD 

TAD  Master 

Personal  PRT 

Results 

Lists  all  PRT  entries  for  a  specified 
command  member 

Select 

PRT  Data 

Sailor 

Personal  Sick  Days 

Lists  all  workdays  missed  due  to  illness 
for  a  specified  command  member 

Select 

Binnacle  List 

Sailor 

Promote  Sailor 

Changes  a  specified  command 
member’s  rank 

Select  . 
Update 

Sailor 

PRT  Entry 

Ad^  an  individual  PRT  entry 

Insert 

PRT  Data 

Sailor  Address 

Changes  the  address  of  a  specified 
command  member 

Select 

Update 

Sailor 

Sailor  Marital  Status 

Removes  the  spouse  of  a  specified 
command  member 

Select 

Update 

Sailor 

Spouses 

Spouses 

Lists  the  spouse  of  a  specified 
command  member 

Select 

Sailor 

Spouses 

Travel  Claims 

Lists  all  details  of  an  individual  travel 
claim 

Select 

TAD 

TAD  Cost 

TAD  Master 

Figure  15.  Administration  Main  Page  Operations 
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2.  Budget  and  Supply 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables 
and  fields 

All  Budget  Totals 

By  Date 

Calculates  the  total  expenditures  of  a 
specified  command  by  selected  budget 
line  item  for  a  given  timeframe 

Select 

Expenses 

Properties  Listing 
Purchase  Categories 

TAD 

TAD  Cost 

Assign  Minor 
Property  Custody 

Assigns  minor  property  custody  to  a 
specified  command  member 

Select 

Update 

Properties  Listing 

Dispose  of  Minor 
Property 

Removes  minor  property  from  a 
specified  command's  inventory 

Select 

Update 

Properties  Listing 

General  Expenses 
and  Purchases 

Adds  a  record  of  purchase  for  general 
items  to  a  specified  command 

Insert 

Expenses 

General 

Expenditures  By 

Date 

Lists  all  general  expenditures  of  a 
specified  command  for  a  given 
timeframe 

Select 

Billet  Occupation 
Command  Information 
Expenses 

Sailor 

Stock  Item  Descriptions 

General 

Expenditures  By 

Item 

Lists  all  information  about  a  command 
general  purchase  by  item  number 

Select 

Billet  Occupation 
Conmiand  Information 
Expenses 

Sailor 

Stock  Item  Descriptions 

Liquidate  Travel 
Claim 

Assigns  liquidated  values  to  specified 
command  travel  claims 

Update 

TAD 

TAD  Cost 

Minor  Property 
Custody  Listing 

Adds  a  record  of  purchase  for  minor 
property  to  a  specified  command 

Insert 

Properties  Listing 

Minor  Property 
Expenditures  By 

Date 

Lists  all  minor  property  purchases  for  a 
specified  command  for  a  given 
timeframe 

Select 

Command  Information 
Properties  Listing 

Sailor 

Minor  Property 
Expenditures  By 

Item 

Lists  all  minor  property  purchase  data 
by  item  number  for  a  specified 
command  over  a  given  timeframe 

Select 

Command  Information 
Properties  Listing 

Sailor 

Minor  Property 
Purchases 

Adds  a  record  of  purchase  of  minor 
property  to  a  specified  command 

Insert 

Properties  Listing 

Figure  16.  Budget  and  Supply  Main  Page  Operations 
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3. 


Command 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables 
and  fields 

Add  New 

Department 

Adds  a  new  department  to  a  specified 
command 

Insert 

Department 

Add  New  Division 

Adds  a  new  division  to  a  specified 
command 

Insert 

Division 

Annual  Balance 
Report 

Calculates  the  account  balances  of 
specified  budget  line  items  for  a 
selected  command  over  a  given 
timeframe 

Select 

Expenses 

Fiscal  Authorization 
Properties  Listing 
Purchase  Categories 

TAD 

TAD  Cost 

Billets  FiUed 

Lists  all  manned  billets  at  a  specified 
command 

Select 

Authorization  of  Billets 
Billet  Occupation 
Command  Information 
Sailor 

Billet  Structure 

Lists  all  billets  assigned  to  a  command 

Select 

Authorization  of  Billets 
Conunand  Information 

Binnacle  List 
Statistics 

Calculates  total  days  lost  due  to  illness 
or  injury  at  a  specified  command 

Select 

Binnacle  List 

Command  Information 

Change  Department 
Information 

Changes  department  data  at  a  specified 
command 

Insert 

Update 

Select 

Department 

Sailor 

Change  Division 
Information 

Changes  division  data  at  a  specified 
command 

Insert 

Update 

Select 

Division 

Sailor 

Command 
Demographics  By 
Gender 

Sums  all  active  members  of  a  specified 
command  by  gender 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Command 
Demographics  By 
NEC 

Sums  all  active  members  of  a  specified 
command  by  NEC 

Select 

Billet  Occupation 
Command  Information 
Sailor- 

Command 
Demographics  By 
Rank 

Sums  all  active  members  of  a  specified 
command  by  rank 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Command 
Demographics  By 
Rate 

Sums  all  active  members  of  a  specified 
conunand  by  rating 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Command  Structure 

Lists  the  structure  of  a  specified 
command  and  the  personnel  locally 
assigned  to  key  positions 

Select 

Command  Information 
Department 

Division 

Sailor 

Days  at  Sea 

Calculates  the  number  of  days 
members  of  a  specified  command  have 
spent  deployed  to  sea 

Select 

Command  Information 
TAD 

TAD  Master 

Emergency  Recall 

List 

Lists  points  of  contact  for  key 
personnel  at  a  specified  command 

Select 

Command  Information 
Department 

Sailor 

Figure  17.  Command  Main  Page  Operations 
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Flight  Hours  By 
Mission 

Sums  all  flight  hours  for  members  of  a 
specified  command  and  lists  these  by 
individual  flight  mission  over  a  given 
timeframe 

Select 

Air  Crews 

Command  Information 
Flight  Mission 

Flight  Hours  Total 

Calculates  the  total  number  of  flight 
hours  flown  by  a  specified  command 
for  a  given  timeframe 

Select 

Air  Crews 

Command  Information 
Flight  Mission 

PRT  Report 

Lists  all  members  and  their  PRT  scores 
of  a  specified  command  by  PRT  level 
for  a  given  timeframe 

Select 

PRT  Data 

Sailor 

Quarterly  Balance 
Report 

Calculates  the  account  balances  of 
specified  budget  line  items  for  a 
selected  command  over  a  quarterly 
timeframe 

Select 

Expenses 

Fiscal  Authorization 
Properties  Listing 
Purchase  Categories 

TAD 

TAD  Cost 

Reenlist  Sailor 

Changes  reenlistment  and  EAOS  data 
for  a  specified  command  member 

Select 

Update 

EAOS  Data 

Retention  Statistics 

Compares  the  totals  of  command 
members  who  reenlisted  to  those 
eligible  for  reenlistment  for  a  specified 
command  over  a  given  timeframe 

Select 

Billet  Occupation 
Command  Information 
EAOS  Data 

Sailor 

Roster 

Lists  name,  rank  and  social  security 
number  for  all  members  of  a  specified 
command 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Sailor  Check-in  at 
Command 

Adds  a  sailor  to  a  specified  command 

Update 

Billet  Occupation 

TAD  Report 

Lists  all  members  of  a  specified 
command  and  the  total  ^ys  deployed 
by  trip  for  a  selected  TAD  category 
who  have  departed  within  a  given 
timeframe 

Select 

Billet  Occupation 
Command  Information 
Sailor 

TAD 

TAD  Master 

Transfer  Sailor 

Releases  a  specified  command  member 
from  a  selected  command 

Select 

Update 

Billet  Occupation 
Department 

Division 

Properties  Listing 

Upcoming 

Reenlistments 

Lists  all  members  of  a  specified 
command  who  are  eligible  for 
reenlistment  within  90  days  of  today's 
date 

Select 

Billet  Occupation 
Command  Information 
EAOS  Data 

Sailor 

Figure  17.  Command  Main  Page  Operations  (cont.) 
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4. 


General 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables 
and  fields 

Command  Directory 

Lists  official  contact  points  for  key 
departments  and  divisions  of  a 
specified  command 

Select 

Command  Information 
Department 

Division 

Cryptologic  Officer 
Listing 

Lists  the  names  and  dates  of  rank  of  all 
officers  within  the  NSG  claimancy 

Select 

Sailor 

Detailer  Report 

Lists  all  available  NSG  positions 
corresponding  to  specified  billet  criteria 
for  a  given  timeframe 

Select 

Authorization  of  Billets 
Billet  Occupation 
Command  Information 
Duty  Type  Description 

NSG  Command 
Listing 

Lists  the  names  and  address  of  all 
active  NSG  commands 

Select 

Command  Information 

Personnel  Locator 

Lists  a  current  official  point  of  contact 
for  a  specified  individual 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Figure  18.  General  Main  Page  Operations 


5.  Headquarters 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables 
and  fields 

Add  Command 

Adds  a  new  command  to  the  NSG 
claimancy 

Insert 

Select 

Command  Information 

Add  Conference 

Adds  a  new  conference 

Insert 

Select 

TAD  Master 

Add  PMS  Task 

Adds  a  new  PMS  line  item 

Insert 

Select 

PMS  Description 

Add  Sailor 

Adds  a  new  sailor  to  the  NSG 

Insert 

Select 

Sailor 

Add  Supply  Stock 
Number 

Adds  a  new  stock  item 

Insert 

Select 

Stock  Item  Descriptions 

Add  Training  Event 

Adds  a  new  training  line  item  or 
qualification 

Insert 

Select 

Training  Descriptions 

Authorize  Billet 

Adds  a  new  billet  to  a  specified 
command 

Insert 

Select 

Authorization  of  Billets 

Binnacle  List 
Statistics 

Calculates  the  number  of  days  lost  at 
all  NSG  commands 

Select 

Binnacle  List 

Command  Information 

Command  Budgets 

Lists  the  budget  allowances  of  each 

NSG  command  for  a  given  fiscal 
timeframe 

Select 

Command  Information 
Fiscal  Authorization 
Purchase  Categories 

Commanding 

Officer  Listing 

Lists  the  commanding  ofiicers  of  all 

NSG  commands 

Select 

Billet  Occupation 
Command  Information 
Department 

Sailor 

Figure  19.  Headquarters  Main  Page  Operations 
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Days  at  Sea 

Calculates  the  total  days  deployed  to 
sea  throughout  all  NSG  commands  for 
a  given  timeframe 

Select 

TAD 

TAD  Master 

Discharge  Sailor 

Removes  a  sailor  from  the  NSG 
claimancy 

Insert 

Select 

Department 

Division 

EAOS  Data 

Properties  Listing 

Demographics  By 
Gender 

Sums  all  active  members  of  all  NSG 
commands  by  gender 

Select 

Billet  Occupation 

Sailor 

Demographics  By 
NEC 

Sums  all  active  members  of  all  NSG 
commands  by  NEC 

Select 

Billet  Occupation 

Sailor 

Demographics  By 
Rank 

Sums  all  active  members  of  all  NSG 
commands  by  rank 

Select 

Billet  Occupation 

Sailor 

Demographics  By 
Rate 

Sums  all  active  members  of  all  NSG 
commands  by  rating 

Select 

Billet  Occupation 

Sailor 

Flight  Hours 

Calculates  the  total  number  of  flight 
hours  flown  throughout  the  NSG  by 
command  for  a  given  timeframe 

Select 

Air  Crews 

Command  Information 
Flight  Mission 

Order  Sailor  To 
Command 

Assigns  a  NSG  sailor  to  a  specified 
billet  at  a  selected  command 

Insert 

Billet  Occupation 

Personnel  Listing 

Lists  name,  rank  and  social  security 
munber  for  all  members  by  command 

Select 

Billet  Occupation 
Command  Information 
Sailor 

Retention  Statistics 

Compares  the  totals  of  NSG  members 
who  reenlisted  to  those  eligible  for 
reenlistment  for  a  given  timeframe 

Select 

Billet  Occupation 

EAOS  Data 

Sailor 

Retirements 

Lists  all  former  NSG  personnel  who 
have  retired  during  a  given  timeframe 

Select 

EAOS  Data 

Sailor 

Retire  Sailor 

Retires  an  NSG  sailor  from  the  NSG 
claimancy 

Department 

Division 

EAOS  Data 

Properties  Listing 

Sailor  Duty  History 

Lists  all  career  billets  and  command 
assignments  for  a  specified  NSG 
member 

Select 

Authorization  of  Billets 
Billet  Occupation 
Command  Information 
Sailor 

Set  Command 

Budget 

Assigns  a  monetary  amount  to  a 
specified  budget  line  item  for  a 
specified  command 

Insert 

Select 

Fiscal  Authorization 

Unliquidated  Travel 
Claims 

Lists  all  travel  claims  throughout  NSG 
commands  that  are  not  liquidated 

Select 

TAD 

TAD  Cost 

TAD  Master 

Figure  19.  Headquarters  Main  Page  Operations  (cont.) 
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6. 


Maintenance 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables  and 
fields 

Command/Department 
Maintenance  Records 

Lists  all  maintenance  conducted  for 
a  specified  department  at  a  selected 
command  for  a  given  timeframe 

Select 

Command  Information 
Maintenance 

PMS  Description 

Full  Maintenance  List 

Lists  chronologically  all 
maintenance  ever  conducted  at  a 
specified  command 

Select 

Command  Information 
Maintenance 

PMS  Description 

Item  Maintenance 
History 

Lists  all  maintenance  conducted  on 
a  specified  item 

Select 

Maintenance 

PMS  Description 
Properties  Listing 

Maintenance  Log 

Adds  a  completed  maintenance 
record 

Insert 

Update 

Maintenance 

Personal  Maintenance 
Log 

Lists  all  maintenance  conducted  by 
a  command  member  during  a  given 
timeframe 

Select 

Maintenance 

PMS  Description 

Sailor 

Upcoming 

Maintenance  Tasks 

Lists  all  maintenance  required  for  a 
specified  department  and  command 
within 

Select 

Command  Information 
Maintenance 

PMS  Description 

Figure  20.  Maintenance  Main  Page  Operations 


7.  Operations  and  Training 


Hyperlink  name 

Function 

SQL 

operation 

Affected  tables  and 
fields 

Add  Air  Mission 

Adds  a  completed  flight  mission 

Insert 

Select 

Flight  Mission 

Add  Sea  Mission 

Adds  a  completed  sea  mission 

Insert 

Select 

Sea  Mission 

*  Air  Missions  Query 

Lists  all  air  missions  flown 
specified  by  mission  area,  mission 
type,  platform,  and  squadron 
during  a  given  timefrWe 

Select 

Flight  Mission 

Mission  Area  Description 

*Air  Missions  Aircraft 
BuNo  Sort 

Lists  all  air  missions  flown  by 
aircraft  bureau  number  during  a 
given  timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Exercise 

Lists  all  air  missions  flown  by 
exercise  name  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Mission  Area 

Lists  all  air  missions  flown  by 
mission  area  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Mission  Type 

Lists  all  air  missions  flown  by 
mission  type  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Platform  Type 

Lists  all  air  missions  flown  by 
aircraft  type  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

Figure  21 .  Operations  and  Training  Main  Page  Operations 
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*  Air  Missions  -  Sort 

By  Squadron  and  Crew 

Lists  all  air  missions  flown  by 
squadron  and  crew  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Staging  Area 

Lists  all  air  missions  flown  by 
aircraft  bureau  number  during  a 
given  timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Missions  -  Sort 

By  Time 

Lists  all  air  irussions 
chronologically  during  a  given 
timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*  Air  Mission  -  Sort  By 
Track 

Lists  all  air  missions  flown  by  air 
track  during  a  given  timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

*A11  Missions  Query 

Lists  all  operational  missions 
specified  by  exercise  name, 
mission  area,  and  mission  type 
during  a  given  timeframe 

Select 

Flight  Mission 

Mission  Area  Description 

Sea  Mission 

Completed  Training 

Adds  a  completed  training  event 
or  qualification 

Insert 

Update 

Qualification  and  Training 

Personal  Days  at  Sea 

By  Platform 

Calculates  the  number  of  days  at 
sea  for  a  specified  individual  by 
platform  for  a  given  timeframe 

Select 

TAD 

TAD  Master 

Sailor 

Personal  Days  at  Sea 
Career 

Calculates  the  total  number  of 
days  at  sea  for  a  specified 
command  member 

Select 

TAD 

TAD  Master 

Sailor 

Personal  Flight  Hours 
By  Mission 

Lists  all  flights  flown  by  a 
specified  command  member 
during  a  given  timeframe 

Select 

Air  Crews 

Flight  Mission 

Sailor 

Personal  Flight  Hoirrs 
Career 

Calculates  the  total  flight  hours 
for  a  specified  individual 

Select 

Air  Crews 

Flight  Mission 

Sailor 

Personal  Training 
History 

Lists  all  training  completed  for  a 
specified  individual 

Select 

Qualification  and  Training 
Sailor 

Training  Descriptions 

Qualification/Training 
Delinquent  List 

Lists  all  training  and 
qualifications  at  a  specified 
conunand  that  will  expire  within 

90  days 

Select 

Qualification  and  Training 
Sailor 

Training  Descriptions 

*Sea  Missions  Query 

Lists  all  sea  based  missions 
specified  by  mission  area,  mission 
type,  and  platform  type  during  a 
given  timeframe 

Select 

Mission  Area  Description 

Sea  Mission 

*Sea  Missions  -  Sort 

By  Exercise 

Lists  all  sea  based  missions  by 
exercise  name  during  a  given 
timeframe 

Select 

Mission  Area  Description 

Sea  Mission 

*Sea  Missions  -  Sort 

By  Mission  Area 

Lists  all  sea  based  missions  by 
nussion  area  during  a  given 
timeframe 

Select 

Mission  Area  Description 

Sea  Mission 

*Sea  Missions  -  Sort 

By  Mission  Type 

Lists  all  sea  based  missions  by 
mission  type  during  a  given 
timefinme 

Select 

Mission  Area  Description 

Sea  Mission 

*Sea  Missions  -  Sort 

By  Platform  Mode 

Lists  all  sea  based  missions  by 
platform  mode  during  a  given 
timeframe 

Select 

Mission  Area  Description 

Sea  Mission 

Figure  2 

.  Operations  and  Training  Main  Page  Operations  (cont.) 
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*Sea  Missions  -  Sort 

By  Platform  Name 

Lists  all  sea  based  missions  by 
platform  name  during  a  given 
timeframe 

Select 

Mission  Area  Description 
Sea  Mission 

*Sea  Missions  -  Sort 

By  Platform  Side 
Number 

Lists  all  sea  based  missions  by 
platform  number  during  a  given 
timeframe 

Select 

Mission  Area  Description 
Sea  Mission 

*Sea  Missions  -  Sort 

By  Platform  Type 

Lists  all  sea  based  missions  by 
platform  type  during  a  given 
timeframe 

Select 

Mission  Area  Description 
Sea  Mission 

*Sea  Missions  -  Sort 

By  Time 

Lists  all  sea  based  missions 
chronologically  during  a  given 
timeframe 

Select 

Mission  Area  Description 

Sea  Mission 

*  Indicates  that  this  query  is  reached  through  the  additional  Operations  and  Training  page  hyperlink  "All 
Missions" 

Figure  21 .  Operations  and  Training  Main  Page  Operations  (cont.) 


C.  SAMPLE  DATA 

Actual  data  from  NSG  operations  was  not  used  to  populate  the  sample  EIS. 
However  in  order  to  illustrate  system  functionality,  data  has  been  entered  into  the  system 
that  closely  resembles  possible  events  that  occur  daily  within  the  NSG.  Each  of  the 
aforementioned  EIS  functional  groups  tables  contains  some  data  points  with  which  the 
user  can  experiment. 

Two  shore  based  command  level  units  and  one  staff  element  have  been  created  to 
serve  as  representative  samples.  Each  command  has  been  subdivided  into  appropriate 
departments  and  divisions  and  populated  with  fictitious  officer  and  enlisted  personnel 
from  all  NSG  technical  subspecialties.  Data  on  personnel,  TAD  trips,  budget 
expenditures,  and  other  typical  NSG  operations  have  also  been  included.  Combined,  this 
data  simulates  NSG  operations  for  approximately  100  personnel. 

Due  to  the  amount  of  time  necessary  to  manually  enter  several  years  of  actual 
data,  only  representative  samples  of  each  functional  group  have  been  entered. 
Approximately  five  megabytes  of  data  currently  reside  in  the  sample  EIS  server. 
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Vn.  SECURITY 


A.  BASIC  DATABASE  SECURITY 

For  a  database  system  to  be  reliable,  the  data  it  contains  must  be  accurate  and 
complete.  In  order  to  achieve  a  high  degree  of  reliability,  the  database  designer  must 
consider  the  security  of  the  system.  The  principal  concerns  of  database  security  are  data 
integrity,  data  privacy,  and  data  availability  [Ref  14]. 

1.  Data  Integrity 

A  database  query  will  only  return  correct  results  if  it  has  trustworthy  data  upon 
which  to  base  a  conclusion.  To  guarantee  data  integrity  is  to  certify  that  all  the  data  in 
the  database  is  factual  and  of  the  correct  type. 

Data  integrity  also  implies  that  data  updates  cannot  be  repudiated  once 
committed.  Data  transactions  must  be  verifiable,  committed  only  by  authorized 
personnel,  and  impossible  to  change  or  undo.  Protecting  the  integrity  of  data  is  crucial  to 
the  proper  operation  of  an  EIS. 

2.  Data  Privacy 

Certain  combinations  of  database  data  should  not  be  accessible  by  everyone. 
Some  information  needs  to  be  seen  only  by  supervisory  personnel  while  other  data  is 
simply  private.  Good  examples  within  the  NSG  EIS  are  personal  data,  such  as  family 
information  or  social  security  numbers,  and  claimancy  fiscal  data.  Ref  15  gives  a  listing 
of  privacy  related  information  that  should  be  protected. 

Releasing  data  on  a  strict  need-to-know  basis  is  a  staple  of  military  operations.  In 
order  to  ensure  data  privacy,  some  means  of  authenticating  an  authorized  user  to  the 
appropriate  data  object  must  be  assured. 
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3.  Data  Availability 

If  the  EIS  is  to  be  useful  to  the  community  as  a  whole,  the  availability  of  the  data 
through  the  server  must  be  maintained.  Because  it  is  designed  to  be  accessible  through 
the  Internet,  an  EIS  is  more  vulnerable  to  data  availability  attacks  than  a  stand-alone 
database  system.  If  access  to  the  database  server  can  be  blocked,  access  to  the  data  it 
contains  is  denied.  An  EIS  that  is  unavailable  to  the  enterprise  is  on  little  use. 

B.  SYSTEM  SPECIFICATIONS 

1.  Overview 

The  NSG  EIS  is  designed  to  be  accessible  by  anyone  only  through  the  Internet. 
Although  there  are  numerous  computer  system  attacks  that  encompass  a  wide  variety  of 
computing  techniques,  safeguarding  against  all  network  attacks  is  beyond  the  scope  of 
this  thesis.  This  chapter  deals  with  security  concerns  encountered  through  the  legitimate 
use  of  the  system. 

The  web  server  (HTTP  protocol)  is  not  the  only  service  that  allows  a  user  to 
network  to  a  computer.  File  Transfer  Protocol  (FTP),  Gopher,  telnet  and  many  other 
network  applications  have  been  designed  to  allow  computers  to  communicate  with  one 
another.  At  the  sample  site,  most  of  these  services  have  been  intentionally  disconnected 
in  order  to  restrict  unauthorized  access  to  the  server  and  to  maximize  system  resources. 

In  addition,  the  security  weaknesses  of  the  Microsoft  NT  operating  system  are  not 
specifically  addressed  here.  The  National  Security  Agency  has  documented  a 
comprehensive  listing  of  Microsoft  NT  security  problems  and  potential  solutions  in  Ref. 
16. 
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Personnel  can  access  the  database  through  the  Naval  Postgraduate  School  "1-net" 
or  through  the  keyboard  interface  at  the  server  terminal.  Legitimate  Internet  access  is 
gained  only  through  the  client's  use  of  a  web  browser  to  connect  to  the  site's  IIS  web 
server.  The  specific  order  of  events  that  must  occur  in  order  for  data  to  be  retrieved  from 
the  database  is  listed  below.  Each  of  these  events  involves  communications  between  the 
server's  NT  operating  system,  the  web  server  and  the  database  server. 

1 .  A  client  contacts  the  site's  web  server  by  entering  the  site's  URL. 

2.  Upon  contact,  the  site's  web  server  confers  with  the  server  operating 
system  for  the  resources  to  grant  the  user's  connection  request. 

3.  The  web  server  locates  its  default  page,  the  first  page  to  be  presented  to 
the  user. 

4.  Each  web  directory  possesses  a  unique  list  of  authorized  viewers.  If 
anonymous  web  access  is  permitted,  the  web  server  presents  the  default 
page  to  the  user.  Otherwise,  the  user  is  presented  with  a  login  script  that 
the  web  server  must  validate  with  the  operating  system. 

5.  If  a  selected  operation  also  involves  a  connection  to  the  database,  the  web 
server  communicates  to  the  operating  system  that  the  database  server  is 
needed. 

6.  The  operating  system  communicates  this  request  to  the  database  server 
along  with  the  identification  of  the  user. 

7.  Like  the  web  server,  the  database  server  contains  a  separate  control  list 
that  it  uses  to  determine  access  to  the  data.  It  compares  the  user's 
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identification  to  its  listing  and  completes  any  data  request  based  on  a  set  of 
permissions. 

8.  If  the  user  is  recognized,  the  data  is  fetched  from  the  database  and  sent 
back  to  the  operating  system  for  further  transport  to  the  web  server  and 
presentation  to  the  user.  If  the  user  is  not  permitted  access  to  the  data,  an 
appropriate  message  is  passed  in  lieu  of  the  data. 

An  overall  view  of  these  procedures  within  the  NSG  EIS  is  depicted  below  in 
Figure  22. 


As  described  above,  both  IIS  3.0  and  SQL  Server  6.5  have  their  own  separate 
security  features.  Each  of  these  depends  to  some  degree  on  the  capabilities  of  the 
Microsoft  NT  operating  system. 
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The  operating  system  software  constructs  a  default  access  control  list  (ACL) 
when  initially  installed  that  describes  who  may  access  the  server.  The  ACL  is  based  on  a 
set  of  security  policies  that  can  be  altered  by  the  SA.  Thus,  the  SA  decides  who  may  gain 
entry  to  the  system  by  changing  the  ACL  and  how  access  may  be  gained  by  changing  the 
system  security  policies. 

Similarly,  the  SA  constructs  an  ACL  for  each  web  page  and  for  each  SQL  server 
database.  The  operating  system,  the  web  server  and  the  database  server  are  all  configured 
independently  but  reference  the  NT  ACL  to  define  user  access  to  individual  web  pages 
and  the  database.  The  separate  configurations  of  the  operating  system,  the  web  server, 
and  the  database  server  are  examined  in  detail  in  the  following  sections. 

By  tailoring  individual  security  policies  and  ACLs,  the  web  server  and  database 
server  can  select  which  users  may  view  certain  web  pages  and  which  users  may  affect 
data.  The  responsibility  of  the  web  server  and  database  server  with  respect  to  data 


integrity,  data  privacy,  and  data  availability  are  listed  below  in  Figure  23. 


ns 

SQL  Server 

Data  Integrity 

Ensures  that  only  appropriate 
individuals  may  access  web 
pages.  As  web  pages  contain 
data  insert  and  update  routines, 
only  authorized  personnel  may 
alter  data. 

Allows  only  certain  data 
operations  for  selected  database 
tables. 

Allows  only  preformatted  forms 
to  be  presented  to  users. 

Data  Privacy 

Allows  only  appropriate 

individuals  access  to  web  pages 
containing  query  routines  that 
return  sensitive  data. 

Allows  only  authorized 

individuals  to  conduct  queries  of 
certain  tables. 

Data  Availability 

Refuses  web  connections  by 
other  than  authorized  users. 

Refuses  database  connections  by 
other  than  authorized  users. 

Figure  23.  NSG  EIS  Server  Security  Features 
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2.  Operating  System  Security  Configuration 

The  Microsoft  NT  operating  system  has  increased  in  popularity  primarily  due  to 
its  ease  of  use.  Its  availability  and  wide  use  have  also  made  it  the  target  of  choice  by 
hackers  [Ref  16:  p.  1],  A  listing  of  its  vulnerabilities  is  readily  available  on  the  Internet. 
Though  not  designed  for  use  in  a  highly  secure  environment,  Microsoft  has  taken 
significant  steps  to  contain  these  vulnerabilities  and  upgrade  NT  security  features.  The 
NSA  ref  contains  a  listing  of  necessary  configuration  changes  in  order  to  upgrade  the 
security  classification  of  the  system  to  its  highest  possible  (C2)  level  of  trust. 

The  Microsoft  NT  operating  system  collects  most  administrative  functions  into  a 
set  of  functions  known  as  Administrative  Tools.  Using  these  tools,  domains  are  created 
to  partition  work  among  computers  and  users  and  maximize  system  resources.  A  domain 
is  technically  defined  as  "a  collection  of  computers  and  users  that  share  a  common 
directory  services  database  [Ref  16:  p.  8]."  Multiple  domains  may  exist  on  the  same 
server. 

In  addition,  the  SA  is  allowed  to  create  groups  of  users.  Groups  are  defined  in 
order  to  allow  numerous  people  with  similar  working  responsibilities  to  have  the  same 
permissions.  Groups  allow  the  SA  to  classify  users  according  to  how  they  use  the 
computer  system. 

Once  a  domain  and  group  have  been  established,  the  SA  may  add  a  user  and  their 
password  to  the  ACL.  When  a  user  logs  onto  the  NT  server,  the  operating  system  cross- 
references  the  login  name  to  a  security  identifier  that  was  created  when  the  SA  created 
the  users  account.  This  security  identifier  is  unique  to  the  system  and  is  never  displayed. 
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Within  the  NT  environment,  all  system  resources  are  treated  as  separate  objects. 
The  ACL  matches  the  user's  security  identifier  to  the  specified  objects  that  the  SA  deems 
appropriate.  The  ACL  delineates  all  the  rights  that  a  user  possesses  within  the  system. 

The  security  configuration  of  the  operating  system  needs  little  change  for 
legitimate  usage.  Only  one  domain  has  been  created  and  all  default  groups  have  been 
maintained.  New  users  have  been  added  only  to  the  Administrator  group,  the  Users 
group,  or  the  Guests  group.  The  guest  account  has  been  retained  for  anonymous  login 
purposes  only.  This  group  would  be  removed  and  an  NSG-wide  group  and  password 
created  upon  actual  implementation.  All  other  groups  have  been  removed  from  the  NT 
operating  system. 

3.  Web  Server  Security  Configuration 

The  ns  3.0  security  options  allow  the  system  to  differentiate  between  all  users 
based  on  a  user-input  name  and  password.  Recognized  users  are  allowed  to  view 
specified  web  pages  based  on  a  comparison  against  the  pre-established  individual 
permissions. 

A  web  page  must  be  contained  in  a  directory.  Directories  are  grouped  separately 
by  the  web  author  in  the  web  server.  One  directory  must  be  fixed  as  the  root  directory. 
Using  the  default  settings,  the  root  directory  is  the  first  directory  accessed  by  IIS.  In 
addition,  one  page  within  each  subdirectory  must  be  labeled  as  the  default  page  for  that 
directory. 

When  the  root  directory  is  created  in  Front  Page  98,  the  web  author  may  specify 
one  of  two  conditions  that  will  determine  what  accesses  to  a  web  page  will  be  allowed: 
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1 .  Only  users  previously  registered  with  the  operating  system  have  browse 
access. 

2.  Everyone  has  browse  access. 

If  the  first  option  is  selected,  the  web  author  must  specify  which  users  will  have 
access.  This  may  be  done  individually  or  by  designating  an  entire  group.  The  directory 
creator  is  presented  with  a  list  of  authorized  NT  users  and  groups  for  the  domain  on 
which  the  web  server  resides.  The  web  author  may  only  select  from  the  list  of  authorized 
users,  groups,  and  domains  created  by  the  SA. 

A  web  designer  usually  wants  to  make  a  site  maximally  available.  A  prohibitive 
amount  of  computer  resources  would  be  needed  if  the  Operating  System  and  Web  Server 
were  required  to  maintain  the  names  and  passwords  for  all  web  users  on  the  Internet.  To 
preserve  computer  resources,  the  DBA  uses  group  permissions  as  much  as  possible. 

To  allow  maximum  access,  the  web  author  selects  the  second  option  to  admit 
anyone  into  the  default  page.  Viewing  subsequent  pages  is  based  on  authenticated 
membership  to  previously  assigned  groups.  In  effect,  anyone  can  visit  the  site  but  only 
approved  individuals  may  view  the  web  pages  the  DBA  has  determined  they  need  to 
know. 

IIS  creates  an  anonymous  user  account  with  a  random  password  when  the  server 
is  installed.  The  anonymous  user  is  logged  in  as  the  user  when  no  special  access  is 
designated  for  a  web  directoiy.  The  system  web  author  may  delete  or  reconfigure  this 
account  through  the  IIS  Internet  Service  Manager.  If  this  account  is  deleted,  a  user  must 
have  an  account  on  the  server  in  order  to  make  an  initial  connection  to  the  web  server. 
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For  non-root  directories,  the  web  author  may  specify  that  a  directory  has  the  same 
permissions  as  the  root  page  or  that  it  has  unique  permissions.  The  first  option  allows  the 
web  author  to  use  the  same  ACL  to  control  multiple  directories.  Unique  permissions  for 
subsequent  directories  are  controlled  in  the  same  manner  as  those  of  the  root  directory. 

The  operating  system  caches  the  user's  last  login.  If  subsequent  web  pages  are 
located  in  the  same  directory  or  the  newly  selected  directory  has  the  same  permissions  as 
the  previous  directory,  no  new  login  is  required.  An  authentication  script  is  invoked  only 
if  the  current  login  does  not  match  the  permission  listed  for  the  newly  selected  directory. 
This  cached  login  is  used  for  database  server  access  as  well.  Database  access  is  discussed 
in  the  next  section. 

For  the  NSG  EIS,  the  web  pages  have  been  sorted  into  the  directories  previously 
described  in  Chapter  VI.  The  anonymous  user  is  allowed  access  only  to  the  root 
directory,  the  general  directory  and  the  guest  book.  Other  directories  contain  user  groups 
and  passwords  unique  to  that  NSG  functional  group.  The  only  legitimate  way  to  access 
unique  group  data  is  through  a  specialized  web  page.  Only  group  personnel  who  are 
listed  in  the  ACL  for  that  page's  directory  and  know  the  proper  password  may  perform 
these  operations. 

Thus,  when  an  NSG  user  uses  a  web  browser  to  access  the  sample  site,  the  root 
directory  default  page  is  presented  through  anonymous  login.  From  here,  the  user  may 
select  a  hyperlink  to  another  page. 

If  this  page  is  other  than  the  general  directoiy  or  the  guest  book,  IIS  presents  an 
authentication  script  to  the  user  who  must  input  a  unique  name  and  password.  nS  will 
pass  this  data  to  the  operating  system  and  check  it  against  the  NT  ACL.  If  the  user  name 
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and  password  match  the  ACL,  and  the  user  is  authorized  for  that  web  directory,  the  user 
is  allowed  to  view  any  page  within  that  directory. 

The  user  can  perform  up  to  three  consecutive  authentication  tries.  If  the  user 
name  and  password  do  not  match,  the  web  server  will  not  retrieve  the  desired  page. 
Instead  it  displays  a  message  saying  that  access  is  denied.  The  user  must  then  use  the 
browser  to  return  to  the  previous  authorized  page.  It  is  possible  for  the  web  author  to 
modify  the  number  of  authentication  attempts  using  the  IIS  Internet  Service  Manager. 


Web  server  authentication  operations  are  depicted  in  Figure  24. 


Figure  24.  IIS  Security 


The  IIS  web  security  features  concentrate  mainly  on  data  privacy.  However,  the 
web-based  interface  allows  the  web  author  to  implement  some  data  integrity  features  as 
well.  For  example,  if  an  authorized  user  attempts  to  insert  the  wrong  data  type  into  a 
field,  the  database  server  rejects  it  and  returns  an  error  message.  Using  preformatted 
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insert  and  update  web  pages,  it  is  possible  to  decrease  reliance  on  the  database  server  to 
solely  filter  out  mismatched  data  types. 

Front  Page  98  allows  the  database  designer  to  construct  forms  that  contain 
syntactically  correct  inputs.  Form  tools  such  as  drop-down  boxes  and  radio  buttons 
require  the  user  to  select  from  valid  entries  instead  of  freely  entering  data.  Ensuring  that 
only  certain  frelds  are  available  to  the  user  helps  preserve  data  integrity  and  reduces 
frustration  on  the  part  of  the  user. 

Using  the  IIS  Internet  Service  Manager,  the  SA  may  specify  the  maximum 
number  of  connections,  the  maximum  data  rate,  and  the  maximum  connection  time  a 
client  may  remain  connected  to  the  server.  In  addition,  certain  computers  may  be  denied 
web  access  based  on  their  IP  address.  Each  of  these  tools  allows  the  SA  to  further 
configure  web  server  security  and  maximize  data  availability. 

To  minimize  remote  access  of  the  operating  system,  actual  implementation  of  the 
NSG  EIS  require  isolating  the  web  server  as  much  as  possible  from  other  system  files. 
This  would  be  best  accomplished  by  mounting  the  web  server  on  a  separate  computer 
configured  solely  for  web  service.  In  this  manner,  web  server  performance  could  be 
optimized,  and  a  security  breach  to  the  web  server  would  not  affect  system  files 
contained  on  the  main  computer. 

4.  Database  Server  Security  Configuration 

Like  the  web  server,  the  database  server  may  be  configured  to  enhance  the 
security  of  the  system  using  a  set  of  security  policies  and  an  ACL.  In  contrast,  the 
database  server  directly  fetches  data  from  the  database.  Through  this  direct  interaction. 
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the  database  server  is  much  more  capable  of  ensuring  data  integrity  and  proper  access  to 
the  database  tables. 

Configuring  security  in  SQL  6.5  requires  using  two  separate  tools.  The  first,  the 
SQL  6.5  Security  Manager  is  very  similar  to  the  NT  Administrative  Tools.  It  allows  the 
DBA  to  define  groups,  users,  and  connection  times  for  each  individual  database. 

The  second  tool,  the  SQL  Server  6.5  Enterprise  Manager,  allows  the  DBA  to 
assign  object  permissions  to  each  of  these  groups  and  user,  where  objects  are  defined  as 
tables  and  fields.  Thus,  users  can  be  granted  delete,  insert,  select,  and  update  authority  by 
field  and  table  in  an  ACL  similar  to,  but  separate  from,  the  NT  ACL.  The  Enterprise 
Manager  affords  a  high  degree  of  granularity  when  granting  database  access. 

When  SQL  Server  6.5  is  installed,  it  loads  a  set  of  security  rules  known  as  the 
default  mode.  When  operating  in  the  default  mode,  any  passwords  that  have  been  input 
to  the  operating  system  are  ignored.  Only  the  user  name  and  password  that  have  been 
permanently  coded  in  the  DDC  file  are  used  for  database  access. 

For  a  web-based  application  such  as  the  EIS,  this  default  must  be  changed  through 
the  Enterprise  Manager.  In  order  to  implement  a  challenge-response  system,  SQL  Server 
must  be  reset  to  the  integrated  security  mode.  When  operating  in  the  integrated  security 
mode,  the  database  server  uses  the  password  input  for  the  web  server  to  access  the 
database  as  well. 

In  practice,  a  user  requests  access  to  data  by  selecting  a  data  operation  from  a  web 
page.  The  web  server  passes  this  request  to  the  operating  system,  which  in  turn  contacts 
the  database  server.  The  password  that  has  been  cached  by  the  operating  system  is 
passed  to  the  database  server  along  with  the  SQL  statement. 
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When  database  access  is  requested,  the  database  server  checks  this  password 
against  its  ACL  to  determine  whether  this  user  has  sufficient  permission  to  execute  the 
SQL  statement.  Like  IIS  3.0,  either  the  data  or  an  error  message  is  returned  to  the  user. 
SQL  Server  6.5  database  authentication  operations  are  depicted  in  Figure  25. 


SQL  Server  6.5  security  procedures  ensure  that  only  approved  personnel  can  view 
or  modify  tables.  Combining  these  features  with  those  previously  mentioned  for  IIS 
ensure  that  data  integrity  and  data  privacy  are  ensured  for  the  system. 

The  Enterprise  Manager  also  allows  optimization  of  the  database.  The  DBA  may 
specify  how  many  connections  are  allowed  at  a  time,  how  many  objects  and  databases 
may  be  open  simultaneously,  how  long  a  connection  may  remain  idle  before  it  is 
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terminated,  and  how  long  a  user  may  remain  logged  onto  the  database.  Using  these 
configuration  options,  the  DBA  can  help  to  ensure  data  availability. 

Again,  were  the  NSG  EIS  to  be  actually  implemented,  it  would  be  best  to  separate 
the  database  server  from  the  main  file  system.  This  would  allow  the  system  to  be 
optimized  for  performance  and  minimize  system  damage  should  security  be  breached. 

C.  OTHER  SECURITY  FEATURES 

1.  Database  Organization 

Proper  relationships  between  database  tables  and  fields  combined  with  good 
programming  practices  help  protect  against  repudiation  of  data.  All  NSG  EIS  SQL  insert 
and  update  statements  contain  an  if-then  conditional  programming  clause  to  ensure  that 
only  syntactically  correct,  non-duplicate  data  is  entered  into  the  database. 

When  a  user  submits  data,  SQL  Server  6.5  uses  the  EDC  file  to  determine  where 
to  put  the  data.  The  IDC  file  if  clause  checks  the  table  to  see  that  the  table  and  key  value 
exists  and  that  the  data  to  be  entered  is  of  the  correct  type.  In  certain  instances,  other 
fields  may  be  checked  to  ensure  that  a  previous  update  operation  cannot  be  undone.  This 
extra  data  integrity  check  is  dependent  of  the  particular  NSG  EIS  operation.  If  the  data  is 
proper,  then  the  data  is  added  to  the  database.  There  is  no  change  to  the  database  and  an 
error  message  is  returned  to  the  user  otherwise. 

In  addition,  SQL  Server  6.5  observes  the  time  when  an  insert  or  update  operation 
is  conducted  based  on  its  own  internal  clock.  The  software  can  be  made  to  place  this 
timestamp  and  the  logon  id  of  the  user  as  a  field  in  the  appropriate  table  when  a 
transaction  is  conducted.  Separate  constraints  can  be  placed  on  fields  to  specify  valid 
update  times  or  limit  intervals  between  modifications.  Although  these  techniques  were 


78 


not  specifically  used  in  the  NSG  EIS,  their  implementation  would  help  assure  non¬ 
repudiation  of  data  transactions  and  strengthen  data  integrity. 

2.  Logs 

System  logs  are  an  important  security  tool  common  to  most  systems.  Logs  do  not 
prevent  inappropriate  system  usage  but  rather  documents  system  users  and  any  problems 
that  may  have  been  encountered.  Logs  are  usually  considered  legal  documents  and 
should  be  written  to  removable  or  read-only  media  to  prevent  tampering.  NT  provides 
both  an  application  log  and  a  security  log  that  allow  the  SA  to  view  who  has  accessed 
various  portions  of  the  NSG  EIS. 

The  NT  application  log  shows  a  comprehensive  list  of  users  that  have  invoked  the 
database  server.  This  function  allows  the  SA  to  view  the  date,  time,  source,  category, 
event,  and  user  name  each  time  a  query  or  data  operation  has  been  run. 

The  NT  security  log  simply  shows  what  users  have  logged  on  to  the  server.  Like 
the  application  log,  it  lists  the  date,  time,  source,  category,  event,  user  name,  and 
computer  from  which  the  server  has  been  accessed. 

In  addition,  IIS  makes  an  entry  into  a  separate  log  each  time  a  web  page  is 
accessed.  This  log  records  the  date,  the  web  page  accessed,  the  operation  performed  and 
the  IP  address  of  the  machine  that  contacted  the  NSG  server.  A  new  log  file  is  started 
each  day.  The  files  from  previous  days  are  logged  in  the  WINNT\System32  directory. 
The  log  file  name  and  storage  site  are  configurable  by  the  SA. 

It  is  possible  to  log  all  server  users  directly  to  a  SQL  database  table  using  the 
Internet  Service  Manager.  Though  not  initiated  for  the  sample  site,  this  option  allows  the 
DBA  to  automate  routines  to  check  who  is  accessing  the  database  as  well  as  how  and 


79 


when  it  is  being  utilized  and  what  pages  are  being  utilized  the  most.  Such  data  provides  a 
valuable  tool  for  optimizing  database  resources. 

3.  Database  Redundancy  and  Backups 

One  last  fundamental  requirement  of  large  systems  is  backup.  Backups  provide 
recovery  from  system  failure  due  to  system  failure,  security  breach,  and  natural  disaster. 
Databases  should  be  backed  up  to  separate,  removable  media  faithfully  and  frequently. 

SQL  Server  6.5  has  made  the  task  of  backing  up  data  files  simple  for  the  DBA. 
Using  the  Enterprise  Manager,  the  database  schema  and  all  data  can  be  copied  quickly 
and  easily  to  the  local  disk  or  a  remote  server.  The  DBA  need  not  even  be  present  for  the 
backup  to  occur.  Backups  may  be  automatically  scheduled  for  off-peak  computer  times 
to  maximize  NSG  resources. 

Database  recovery  has  also  been  made  rapid  and  straightforward.  The  entire 
database  or  a  portion  thereof  can  be  restored  from  a  local  disk  or  remote  server  using  the 
same  set  of  tools.  The  Enterprise  Manager  fiirther  allows  the  DBA  to  specify  versions  of 
the  database  to  facilitate  good  accounting  practices. 

For  the  NSG  EIS,  back  up  should  be  conducted  locally  daily.  Portable  magnetic 
media  should  be  checked  to  ensure  the  database  has  written  properly,  removed,  and 
stored  for  safekeeping.  Periodically,  this  data  should  be  written  to  permanent  storage 
such  as  a  CD  or  Write  Once  Read  Many  (WORM)  disk.  WORM  media  cannot  be  altered 
and  are  good  tools  for  permanent  archive. 

In  addition,  the  database  should  be  backed  up  remotely  to  protect  against 
catastrophic  failures.  The  NSG  headquarters  has  already  identified  one  stateside 
command  element  whose  primary  responsibility  is  archival  of  NSG  historical  data.  If  the 
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NSG  EIS  were  to  be  implemented,  remote  backup  to  this  site  should  be  conducted  at  a 
minimum  on  a  weekly  basis. 
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vm.  CONCLUSIONS 


A.  SYNOPSIS 

According  to  best  estimates,  the  volume  of  information  in  the  world  doubles 
every  18  months  [Ref  17],  Many  Fortune  500  companies  have  retooled  to  take 
advantage  of  advances  in  computer  technology  and  networking  to  foster  growth  and 
optimize  resources  [Ref.  18],  The  ability  to  bring  accurate  and  timely  information  to  bear 
has  become  a  cornerstone  of  21®*  century  military  operations  as  well. 

The  NSG  must  follow  suit.  The  NSG  has  an  abundance  of  data  stored  in 
disassociated  systems.  Extensive  overhead  forces  management  to  spend  excessive  time 
and  resources  transforming  data  into  useful  information. 

The  proposed  EIS  outlined  in  this  thesis  allows  all  NSG  units  instant  data  access 
from  anywhere.  Any  drawbacks  to  the  system  (more  planning  is  required  to  implement 
an  EIS  securely  and  specialized  configurations  may  be  needed  to  optimize  its 
performance)  are  far  outweighed  by  its  advantages.  The  benefits  of  immediate,  global 
access  at  low  cost  justify  the  extra  effort. 

This  thesis  has  shown  that  it  is  possible  to  implement  an  Enterprise  Information 
System  affordably  and  efficiently  within  the  NSG.  Doing  so  would  optimize  personnel 
efficiency,  maximize  data  accuracy  and  timeliness,  and  reduce  costs.  An  EIS  would 
enhance  the  Naval  Security  Group's  aggressive  pursuit  of  information  dominance. 

B.  AREAS  FOR  FURTHER  RESEARCH 

The  purpose  of  this  thesis  research  is  to  prove  the  feasibility  of  the  NSG  EIS.  The 
associated  sample  site  reflects  only  the  most  basic  application  of  this  thesis  material. 
There  are  many  areas  of  future  research  associated  with  this  project. 
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1.  Automatic  Data  Update 

Much  redundancy  exists  with  the  upkeep  of  military  database  systems.  Just  as  the 
NSG  headquarters  provides  guidance  to  its  units,  various  higher  echelon  entities  of  the 
United  States  Navy  provide  guidance  to  the  NSG. 

The  EIS  sample  site  relies  on  personnel  to  manually  enter  data  into  the  database. 
Other  Navy  sites  already  maintain  much  of  this  data.  For  example,  the  Navy's  Bureau  of 
Personnel,  the  cognizant  authority  on  Navy  manpower,  maintains  very  large  databases 
concerning  billets  and  personnel.  A  regularly  scheduled  data  subscription  to  these 
databases  to  the  NSG  EIS  would  preclude  manual  data  reentry. 

Similarly,  some  shipboard  units  do  not  yet  have  unlimited  network  access.  They 
generate  many  of  the  operational  reports  used  within  the  NSG  operations  and  training 
functional  group.  The  sample  EIS  would  rely  on  shore  based  personnel  to  reenter  report 
data  into  the  database.  As  these  reports  are  transmitted  electronically,  finding  a  way  to 
automatically  update  report  data  to  appropriate  database  fields  would  be  a  worthwhile 
endeavor. 

2.  Data  Integrity  and  Security 

There  are  many  aspects  of  information  security  that  have  not  been  examined  in 
detail  for  this  system.  Configuring  the  NT  operating  system  of  the  sample  site  in 
accordance  with  Ref  16  must  be  implemented  before  the  system  could  be  ported  to  the 
Internet. 

Further,  a  proxy  server  could  be  added  to  serve  as  a  security  firewall.  The 
addition  of  a  proxy  server  would  enhance  the  security  of  the  system  and  allow  the  SA  to 
further  protect  the  main  file  systems  of  the  server. 


The  subject  of  encryption  has  not  been  addressed  in  this  research.  Link 
encryption  through  a  more  trusted  protocol  such  as  secure  HTTP  would  help  to 
strengthen  data  privacy.  Encryption  of  the  data  as  it  resides  in  the  database  server  would 
help  to  preserve  both  data  integrity  and  privacy.  Both  measures  should  be  investigated  if 
the  NSG  EIS  is  to  be  implemented  on  an  insecure  network  such  as  the  Internet. 

Finally,  it  is  not  mandatory  that  the  system  be  fielded  on  the  Internet.  As 
previously  stated  in  the  introduction  section,  most  NSG  units  subscribe  to  more  secure 
networks.  An  investigation  in  how  to  migrate  this  system  to  a  more  secure  network 
would  better  protect  existing  unclassified  data  and  possibly  allow  for  the  limited 
processing  of  some  classified  data. 

3.  Functional  Expansion 

The  existing  EIS  is  far  fi'om  complete  in  its  functionality.  The  expansion  of  its 
capabilities  to  include  additional  NSG  operations  would  be  important.  Notably  missing 
from  the  current  system  are  fixed  site  operational  data,  additional  personnel  information, 
and  safety  information. 

In  addition,  all  implemented  functional  groups  could  be  greatly  expanded  to 
provide  extended  information  to  community  mangers.  Additional  queries  to  include  such 
benchmarks  as  manning  ratios  and  deployment  ratios  would  be  beneficial  to  NSG 
management. 

Finally,  the  design  of  this  system  was  limited  in  scope  to  units  of  the  Naval 
Security  Group.  Other  non-NSG  units  should  also  benefit  from  an  EIS. 
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4.  Increase  User-Friendliness 

SQL  Server  6.5  generates  and  displays  error  messages  specific  to  the  miscue. 
These  messages  are  cryptic  and  difficult  for  even  the  database  designer  to  understand. 
The  database  software  contains  tools  to  tailor  own  error  messages  to  instruct  the  user  as 
to  what  error  has  occurred  and  what  steps  are  needed  in  order  to  correct  it.  Creating  a 
bank  of  such  exceptions  would  increase  the  usability  of  the  system. 

In  addition,  the  interface  could  be  expanded  to  include  features  that  improve  both 
usability  and  flexibility.  Some  interface  construction  software  such  as  JavaScript  contain 
additional  features  that  could  be  added  to  data  entry  forms  and  web  pages  without 
sacrificing  interoperability.  Retooling  the  interface  using  such  devices  would  make  the 
system  more  flexible  and  better  accommodate  naive  and  experienced  users  alike. 

Navigation  of  the  system  is  fairly  straightforward  but  could  be  greatly  enhanced 
with  on-line  help.  Implementing  a  set  of  help  services  would  aid  the  user  as  to  what 
entries  were  appropriate  for  certain  web  pages  and  help  guide  the  user  through  a  desired 
data  operation.  Users  who  are  not  familiar  with  data  keeping  operations,  NSG 
procedures,  or  web  browsers  could  be  readily  walked  through  the  site  with  a  good 
tutorial. 

Finally,  all  data  at  the  sample  site  is  returned  in  text  format.  While  exact,  this  is 
not  always  the  best  method  for  presenting  data  to  a  user.  Much  analysis,  especially 
temporal  analysis,  is  often  better  conducted  using  graphical  tools.  Devising  a  way  to 
return  some  data  sets  in  graphical  form  would  greatly  enhance  the  system. 
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5.  Intelligent  Processes 

The  sample  site  EIS  requires  managerial  personnel  to  periodically  monitor  the 
database  and  perform  limited  analysis  on  data  returned  from  queries.  To  augment  these 
efforts,  a  series  of  intelligent  processes  should  be  created  to  automatically  alert 
supervisory  personnel  that  certain  data  points  have  been  reached  that  are  contrary  to 
preset  tolerances.  The  concept  of  a  manager  getting  email  from  the  EIS  specifying  that  a 
command  has  fallen  below  a  minimal  manning  level  or  that  a  person  is  approaching  the 
flight  hour  limit  for  the  month  is  not  far-fetched. 

6.  Optimization 

Only  about  five  megabytes  of  data  are  currently  present  within  the  database.  No 
effort  has  been  made  to  minimize  memory  space.  Varchar  and  text  data  types  have  been 
maximized  to  provide  the  most  flexibility  for  the  designer.  An  actual  NSG  EIS  would  be 
populated  with  data  from  approximately  11,000  people  and  numerous  commands. 
Without  careful  table  and  field  management,  one  could  quickly  utilize  all  available  disk 
space  to  store  data. 

Many  queries  perform  a  required  calculation  on  the  spot,  return  the  result  to  the 
user  and  then  discard  the  data.  The  result  is  recalculated  the  next  time  the  query  is  called. 
Any  query,  particularly  a  mathematical  calculation,  that  is  submitted  to  a  heavily 
populated  database  can  sort  through  hundreds  of  megabytes  before  the  correct 
combination  of  data  sets  is  recognized,  retrieved  and  returned.  This  translates  to  lost  time 
on  the  part  of  the  user.  A  thorough  examination  of  system  performance,  including  testing 
with  large  sets  of  data  and  storage  of  intermediate  query  results,  would  be  necessary 
before  the  EIS  could  be  realistically  implemented. 
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In  addition,  the  implemented  NSG  EIS  would  allow  hundreds  of  people  to 
concurrently  perform  data  updates  and  queries.  To  handle  large  numbers  of  simultaneous 
connections,  configuration  optimization  would  need  to  be  examined.  Due  to  budgetary 
constraints,  the  sample  site  places  the  file  system,  the  web  server,  and  the  database  server 
all  reside  on  the  same  machine.  Separating  these  would  allow  the  database  administrator 
to  optimize  each  to  peak  performance. 

7.  Upgrades 

At  the  time  of  this  writing,  IIS  4.0  has  been  fielded  and  SQL  Server  7.0  is 
completing  Beta  testing.  The  finalized  versions  of  both  would  be  available  at  no  cost  to 
Microsoft  Development  Network  Subscribers.  Documentation  on  additional  software 
capabilities  and  improvements  are  unavailable.  Upgrading  the  sample  site  to  the  newer 
versions  should  result  in  improvements  in  capacity,  functionality,  and  performance. 
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APPENDIX  A.  ABBREVIATIONS 


ACL  -  Access  Control  List 

COTS  -  Commercial-OfF-the- Shelf 

DBA  -  Database  Administrator 
DBMS  -  Database  Management  System 
DoD  -  Department  of  Defense 
DoN  -  Department  of  the  Navy 

EAOS  -  End  of  Active  Obligated  Service 
EIS  -  Enterprise  Information  System 

FTP  -  File  Transfer  Protocol 

HTM  -  Hypertext  Markup  File 
HTML  -  Hypertext  Markup  Language 
HTTP  -  Hypertext  Transfer  Protocol 
HTX  -  Hypertext  Markup  Template 

IDC  -  Internet  Database  Connector 
IIS  -  Internet  Information  Server 
IP  -  Internet  Protocol 

LAN  -  Local  Area  Network 

NEC  -  Navy  Enlisted  Classification  code 
NPS  -  Naval  Postgraduate  School 
NSG  -  Naval  Security  Group 

ODBC  -  Open  Database  Connectivity 

PMS  -  Preventative  Maintenance  System 
PRT  -  Physical  Readiness  Test 

S  A  -  System  Administrator 
SQL  -  Standard  Query  Language 

TAD  -  Temporary  Assigned  Duty 

UIC  -  Unit  Identification  Code 

URL  -  Universal  Resource  Locator 

WORM  -  Write  Once,  Read  Many 
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APPENDIX  C.  SAMPLE  CODE 


A.  HTM  Fn.E  -  COMMAND  GROUP  MAIN  PAGE 

The  sample  site  Command  Group  main  page  is  shown  below.  The  data  operations 
accessible  to  this  page  are  displayed  as  underlined  hyperlink  selections. 


Insert  Data 


Change  Data 


Query  Database 


Add  New  Division 
Add  New  Department 
Sailor  Check-In 
at  Command 


Command  Structure 
Change  Denartment 
Information 

Billets 

Billets  Filled 

Billet  Structure 

Change  Division 
Information 

Budget  Balances 
Annual  Balance  Report 
Quarterly  Balance  Reoort 

Sailor 

Reenlist  Sailor 

Transfer  Sailor 

Chain  of  Command 
Command  Structure 
Emergency  Recall  List 

Command  Demographics 
Gender 

NEC 

Rank 

Rate 

Miscellaneous 
Binnacle  List  Statistics 

PRT  Report 

Retention  Statistics 
Roster 

Uncoming  Reenlistments 

Operations 

Days  at  Sea  Flight  Hours 
TAD  Report  By  Mission 
Totals 
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B.  HTM  FILE  -  PRT  REPORT  QUERY  (FORM) 

The  sample  site  Command  Group  PRT  query  is  shown  below  as  an  example  of 
HTM  format.  The  form  has  been  displayed  in  graphic  form  vice  HTML  format  to 
preserve  clarity. 


Command  PRT  Statistics 

Please  enter  query  information: 

Please  choose  the  command,  the  PRT  score  category  and  the  timeframe  desired  to  display  a  command's 

PRT  statistics. 

j  NSGA  ^ 

^  Outstanding 
r 

Excellent 

Good 

^  Satisfactoiy 
^  Fail 

Start  Date  . ^ . I 

Stop  Date  . I 
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C.  IDC  FILE  -  SQL  CODE  FOR  PRT  QUERY 

The  corresponding  sample  site  PRT  query  IDC  file  is  displayed  below  as  an 
example  of  a  SQL  statement. 


DATASOURCE:  NSGDB  SQL 
USERNAME:  SA 
TEMPLATE:  PRTCOM.HTX 
SQLSTATEMENT : 

+SELECT  SAILOR. RANK_RATE, 

+  SAI LOR . FI RS TNAME , 

+  SAI LOR . LAS TNAME , 

+  SAILOR. SEX, 

+  PRT_DATA . COMMAND_I D , 

+  PRT_DATA.PRT_IDENTIFIER, 

+  PRT_DATA. SOCIAL_SECURITY_NUMBER, 

+  PRT_DATA . HEIGHT , 

+  PRT_DATA. WEIGHT, 

+  PRT_DATA. PUSHUPS , 

+  PRT_DATA.SITUPS, 

+  PRT_DATA.RUN_TIME, 

+  CONVERT  (CHAR (12),  PRT_DATA. PRT_DATE,  107)  AS  DATEX, 

+  PRT_DATA. STATUS , 

+  COMMAND_INFORMATION .  COMMAND_NAME 

+  FROM  SAILOR  INNER  JOIN  PRT_DATA  INNER  JOIN  COMMAND_INFORMATION  ON 
+  PRT_DATA.COMMAND_ID  =  COMMAND_INFORMATION .  COMMAND_ID  ON 

+  SAILOR.  SOCIAL_SECURITY_NUMBER  =  PRT_DATA.  SOCIAL_SECURITY  NUMBER 

+  WHERE  (PRT_DATA.COMMAND_ID  =  ' %COMMAND_ID% '  )  AND  ~ 

+  (PRT_DATA. STATUS  =  '%STATUS1%'  OR 

+  PRT_DATA. STATUS  =  '%STATUS2%'  OR 

+  PRT_DATA. STATUS  =  '%STATUS3%'  OR 

+  PRT_DATA. STATUS  =  '%STATUS4%'  OR 

+  PRT_DATA.  STATUS  =  '%STATUS5%')  AND 

+  (PRT_DATA.  PRT_DATE  >=  '  %START_DATE%  '  AND 

+  PRT_DATA.PRT_DATE  <  ' %STOP_DATE% ' ) 

+  ORDER  BY  PRT_DATA. STATUS, 

+  SAI LOR . LAS TNAME , 

+  PRT  DATA. PRT  DATE 
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D.  HTX  FILE  -  RESULTS  FORM 

The  HTX  file  referenced  by  the  above  IDC  file  is  displayed  below  to  demonstrate 
the  HTX  format.  Fields  enclosed  by  the  "<%  %>"  symbol  represent  database  objects 
returned  by  the  database  engine  from  the  corresponding  SQL  query.  If  no  results  are 
returned  from  the  query,  the  default  statement  at  the  base  of  the  file  will  be  displayed. 


Command  PRT  Results 


Rank/ 

Rate 

First 

Name 

Last 

Name 

Sex 

Date 

Height  Weight  Pushups  Situps 

Run 

Time 

Score 

<% 

Rank_ 

<% 

First 

<% 

Last 

<% 

<% 

<%  <% 

<%  <% 

<% 

Pun 

<% 

Rate 

Name 

Name 

Sex 

date 

Height  Weight 

Ihishups  Situps 

XVUll 

Status 

%> 

%> 

%> 

%> 

%>  %> 

%>  %> 

X  Line 

%> 

%> 

Sorry.  No  records  match. 


100 


E.  HTX  FILE  -  RETURNED  QUERY  RESULTS 

The  sample  site  data  set  returned  from  the  query  contained  in  the  form  shown  in 
Appendix  C  Part  B  is  shown  below. 


Command  PRT  Results 


NSGA  Alpha 


Rank/Rate 

First 

Name 

Last 

Name 

Sex  Date 

Height  Weight  Pushups  Situps  Run  Time  Score 

CTOl 

Natalie 

Amsterdam 

F  Feb  05,  1997 

64 

145 

30 

35 

15:15 

F 

CT02 

Arnold 

Bonn 

M  Aug  01,  1997 

68 

145 

35 

35 

14:05 

F 

cm 

Ralph 

Dakota 

M  Aug  01, 1997 

74 

170 

45 

60 

13:45 

F 

CTISN 

Sarah 

Fir 

F  Aug  01, 1997 

69 

160 

40 

32 

14:45 

F 

CTRC 

Cassandra 

Granite 

F  Feb  05,  1997 

68 

155 

15 

30 

14:55 

F 

CTRC 

Cassandra 

Granite 

F  Aug  01, 1997 

68 

151 

15 

29 

14:40 

F 

LTJG 

Sarah 

Slate 

F  Aug  01,  1997 

63 

143 

22 

45 

14:00 

F 

CTM3 

Cheyenne 

Windstar 

F  Aug  01, 1997 

65 

130 

50 

65 

14:49 

F 

LT 

Kevin 

Beige 

M  Feb  05,  1997 

74 

140 

67 

100 

9:55 

0 

CTASN 

Kyle 

Dumas 

M  Feb  05,  1997 

67 

140 

67 

65 

9:35 

O 

CTASN 

Kyle 

Dumas 

M  Aug  01,  1997 

67 

135 

67 

80 

9:33 

O 

CTMC 

Rosemary 

Edsel 

F  Aug  01, 1997 

70 

144 

45 

80 

12:44 

0 

LT 

Elijah 

Gray 

M  Aug  01,  1997 

66 

137 

55 

77 

12:19 

0 

ENS 

April 

Gris 

F  Feb  05,  1997 

69 

135 

50 

100 

09:55 

O 

CTA3 

Perry 

King 

M  Aug  01,  1997 

71 

195 

67 

100 

13:40 

O 

CTM3 

Wally 

Nova 

M  Feb  05,  1997 

67 

160 

67 

100 

09:09 

O 

CTM3 

Wally 

Nova 

M  Aug  01, 1997 

67 

155 

67 

100 

09:15 

0 

CTR2 

Boris 

Quartz 

M  Feb  05,  1997 

74 

205 

67 

100 

09:56 

O 

CTA2 

Tory 

Shelley 

F  Aug  01,  1997 

64 

129 

60 

100 

9:55 

0 

CT02 

Alice 

Stratford 

F  Feb  05,  1997 

64 

120 

55 

100 

09:20 

O 

101 
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INITIAL  DISTRIBUTION  LIST 


Defense  Technical  Information  Center . 

8725  John  J.  Kingman  Road,  Ste  0944 

Ft.  Belvoir,  VA  22060-62 18 

. 2 

Dudley  Knox  Library . 

Naval  Postgraduate  School 

411  DyerRd. 

Monterey,  CA  93943-5101 

. . . 2 

Commanding  Officer . 

(Attn:  Code  30,  CDR  Zellman) 

Naval  Information  Warfare  Activity 

9800  Savage  Rd. 

Ft  Meade,  MD  20755-6000 

. 1 

Commanding  Officer . 

(Attn:  Code  00,  CDR  Arbogast) 

Naval  Security  Group  Activity,  Pensacola  Florida 

475  Jones  Street 

NTTC  Cony  Station 

Pensacola,  FL  325 1 1 

. 1 

Commander  Naval  Security  Group  Command . 

Naval  Security  Group  Headquarters 

9800  Savage  Road,  Suite  6585 

Fort  George  G.  Meade,  MD  20755-6585 

. 2 

Dr.  C.  Thomas  Wu . 

1 

Code  CSAVu 

Naval  Postgraduate  School 

Monterey,  CA  93943-5100 

Commander  Gus  Lott . 

. 1 

Code  EC/Lt 

Naval  Postgraduate  School 
Monterey,  CA  93943-5100 
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LCDR  Jim  Stevenson 
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Portales,  NM  88130 


